Membuat, mengembangkan, dan membuat versi API serta kontrak layanan mikro

  • Artikel

Tip

Konten ini adalah kutipan dari eBook, .NET Microservices Architecture for Containerized .NET Applications, tersedia di .NET Docs atau sebagai PDF yang dapat diunduh gratis dan dapat dibaca secara offline.

Unduh PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

API layanan mikro adalah kontrak antara layanan dengan kliennya. Anda akan bisa mengembangkan layanan mikro secara independen hanya jika Anda tidak memutus kontrak API-nya, itulah alasan mengapa kontrak sangat penting. Jika Anda mengubah kontrak, maka itu akan berdampak pada aplikasi klien atau API Gateway.

Sifat definisi API bergantung pada protokol mana yang sedang Anda gunakan. Misalnya, jika Anda menggunakan olahpesan, seperti AMQP, API terdiri dari jenis pesan. Jika Anda menggunakan layanan HTTP dan RESTful, API terdiri dari URL serta format JSON permintaan dan respons.

Namun, bahkan jika Anda mempertimbangkan kontrak awal dengan baik, API layanan harus berubah dari waktu ke waktu. Ketika hal itu terjadi dan terutama jika API Anda adalah API publik yang digunakan oleh beberapa aplikasi klien, Anda biasanya tidak bisa memaksa semua klien untuk meningkatkan ke kontrak API yang baru. Anda biasanya perlu menyebarkan versi baru layanan secara bertahap, sedemikian rupa sehingga versi lama dan baru dari kontrak layanan dijalankan secara bersamaan. Oleh karena itu, penting untuk memiliki sebuah strategi untuk penerapan versi layanan Anda.

Ketika perubahan API kecil, seperti apabila Anda menambahkan atribut atau parameter ke API, klien yang menggunakan API yang lebih lama harus beralih dan bekerja dengan versi layanan baru. Anda mungkin bisa memberikan nilai default untuk atribut hilang yang diperlukan, dan klien mungkin bisa mengabaikan atribut respons tambahan.

Namun, terkadang Anda harus membuat perubahan besar dan tidak kompatibel pada API layanan. Karena Anda mungkin tidak bisa memaksa aplikasi atau layanan klien untuk segera meningkatkan ke versi yang baru, layanan harus mendukung versi API yang lebih lama untuk beberapa periode. Jika Anda menggunakan mekanisme berbasis HTTP seperti REST, salah satu pendekatannya adalah menyematkan nomor versi API di URL atau ke header HTTP. Kemudian Anda bisa memutuskan antara menerapkan kedua versi layanan secara bersamaan dalam instans layanan yang sama, atau menyebarkan instans yang berbeda yang masing-masing menangani sebuah versi API. Pendekatan yang baik untuk fungsionalitas ini adalah pola Mediator (contohnya, pustaka MediatR) untuk memisahkan berbagai versi implementasi ke dalam penanganan independen.

Terakhir, jika Anda menggunakan arsitektur REST, Hypermedia adalah solusi terbaik untuk membuat versi layanan Anda dan memungkinkan API yang bisa berkembang.

Sumber daya tambahan

SebelumnyaBerikutnya