Materi
Kontrak berubah seiring kebutuhan. Panduan desain API layanan mikro di Azure Architecture Center memisahkan dua jenis perubahan. Menghapus field dari model dapat merusak klien yang mengharapkan field itu ada. Menambah field tidak merusak kompatibilitas, karena klien mengabaikan field yang tidak dikenalinya di respons. Panduan desain web API di situs yang sama menggolongkan penghapusan dan penggantian nama field sebagai perubahan yang dapat merusak klien, dan panduan layanan mikro meminta versi API baru untuk perubahan semacam itu sambil tetap mendukung versi sebelumnya.
| Perubahan | Di respons | Di permintaan |
|---|---|---|
| Menambah field opsional | aman | aman |
| Menambah field wajib | aman bagi klien yang membaca | merusak: klien lama tidak mengirimnya |
| Menghapus field | merusak | aman bila server tidak menolak field lain |
| Mengganti nama field | merusak | merusak bila nama baru wajib |
| Mengubah tipe field | merusak | merusak |
| Field wajib menjadi opsional | merusak: klien bisa menerima respons tanpa field itu | aman |
Arahnya terbalik antara respons dan permintaan. Di respons, klien adalah pembaca, jadi yang merusak adalah hilangnya sesuatu yang dibaca klien. Di permintaan, klien adalah penulis, jadi yang merusak adalah tuntutan baru yang tidak dipenuhi klien lama. Panduan Azure menyebut layanan tetap harus menangani permintaan dari klien lama yang tidak mengirim field baru.
Uji regresi kontrak menjalankan kembali kasus-kasus versi lama terhadap server versi baru. Kasus yang tadinya lulus lalu gagal menandai perubahan yang merusak, dan ditemukan sebelum klien menemukannya di produksi.
