Konteks dan cakupan
SaaS Anda memiliki banyak pelanggan API B2B. Tim ingin mengadopsi Internet-Draft IETF Juni 2026 “A Deprecation Manifest for Field-Level Lifecycle Signalling in HTTP APIs” dan mengekspos application/deprecations+json untuk mendeskripsikan tanggal depresiasi, tanggal sunset, dan pengganti untuk setiap anggota (member) request atau response. Tentukan apakah hal ini layak dijadikan kapabilitas produk dan jelaskan cakupan, nilai bagi pelanggan, kompatibilitas, peluncuran, serta metrik keberhasilan. Draf ini masih berupa pekerjaan yang sedang berjalan (work in progress), bukan RFC final.
Apa yang diuji oleh pewawancara
- Menerjemahkan kapabilitas protokol menjadi masalah pelanggan, alur kerja migrasi, dan nilai bisnis.
- Membedakan header response tingkat resource (RFC 9745, RFC 8594) dari manifest tingkat field.
- Mengontrol komitmen, kompatibilitas, dan tata kelola saat standar belum final.
- Memilih metrik yang dapat diobservasi untuk adopsi, penyelesaian migrasi, dan false positive.
Pertanyaan untuk diklarifikasi sebelum menjawab
- Apakah pelanggan terutama menggunakan SDK, generator OpenAPI, atau parsing JSON langsung?
- Apakah Anda sudah memiliki pemberitahuan depresiasi, kebijakan versi, dan mekanisme notifikasi kontak?
- Apakah anggota yang didepresiasi hanya berupa field response, atau juga field request, array bersarang, dan bentuk polimorfik?
- Apakah tujuannya untuk membantu migrasi manual oleh manusia atau memungkinkan CI/CD dan SDK memblokir risiko secara otomatis?
- Pelanggan, wilayah, atau kasus kepatuhan mana yang mewajibkan anggota lama tetap tersedia, dan untuk berapa lama?
Kerangka jawaban 30 detik
Mulailah dengan masalahnya: pelanggan kesulitan menemukan perubahan tingkat anggota, sementara header Deprecation/Sunset tingkat resource tidak dapat mengidentifikasi setiap anggota. Rekomendasi saya adalah uji coba (pilot) sinyal siklus hidup tingkat field yang terbatas dan opsional, tanpa menyajikan draf tersebut sebagai standar yang stabil. Mulai dengan anggota response, sebuah manifest, tautan dokumentasi, dan field pengganti; pertahankan OpenAPI, pengumuman, dan header tingkat resource. Gunakan tingkat penemuan, waktu migrasi, tingkat false positive, dan tingkat rollback untuk memutuskan apakah perlu memperluasnya.
Pembahasan mendalam langkah demi langkah
1. Tentukan kendala pelanggan dan batasannya
Anggota yang didepresiasi sering kali tetap berada dalam response untuk jangka waktu tertentu. Pelanggan perlu mengetahui anggota mana yang terpengaruh, kapan depresiasi dimulai, kapan penghapusan diperkirakan terjadi, dan apa penggantinya. Manifest menangani penemuan dan orkestrasi; ini tidak mengubah perilaku saat ini dan tidak dapat menggantikan kebijakan versi, contract test, atau komunikasi manusia.
2. Jelaskan hubungannya dengan kapabilitas yang ada
Header tingkat resource tetap menjadi saluran default. Manifest tingkat field dapat ditemukan dengan Link:
Link: </.well-known/deprecations>; rel="deprecation"; type="application/deprecations+json"Contoh manifest:
{
"deprecations": [
{
"target": "response",
"selector": "$.customer.legacy_name",
"selectorType": "jsonpath",
"deprecation": "2026-09-01",
"sunset": "2027-03-01",
"replacement": "$.customer.display_name",
"info": "https://docs.example.com/migrations/customer-name"
}
]
}Desain produk harus memisahkan format, penemuan, dan tata kelola bisnis. Jika draf berubah, pelanggan tetap memiliki dokumentasi yang stabil dan deskripsi OpenAPI.
3. Pilih minimum viable product
Mulai dengan anggota response JSON, satu versi API, dan tanggal yang eksplisit. Jangan menjanjikan setiap dialek JSONPath, varian request-body, bentuk GraphQL, protokol biner, atau penulisan ulang klien otomatis. Pertahankan manifest bersifat read-only dan dapat di-cache, dengan tautan dokumen sumber dan jalur konfirmasi manusia.
4. Rancang peluncuran dan migrasi
Setelah perubahan didaftarkan, platform menghasilkan manifest dan memvalidasi urutan tanggal. Dokumentasi, changelog SDK, dan notifikasi pelanggan dirilis bersamaan. Mulailah dengan API internal dan design partner, lalu perluas ke pelanggan self-serve. Pertahankan riwayat versi dan switch rollback untuk false positive atau perubahan tanggal.
5. Tetapkan tata kelola, kontrol risiko, dan metrik
Tata kelola harus mewajibkan pemilik anggota (member owner), periode pemberitahuan minimum, pengganti yang tersedia, dan persetujuan pengecualian sebelum sunset. Lacak tingkat penemuan manifest, identifikasi panggilan yang terpengaruh, median waktu dari pemberitahuan hingga migrasi, panggilan yang masih menggunakan anggota yang didepresiasi, tingkat false positive, tiket dukungan, dan rollback. Jika pelanggan tidak mem-parsing manifest, investasikan pada pemeriksaan SDK, CLI, atau CI alih-alih menambahkan format.
6. Buat keputusan bertahap
Jika uji coba secara material mengurangi waktu migrasi dengan false positive yang terkendali, perluas ke anggota request dan struktur bersarang. Jika nilai utamanya berasal dari dokumentasi daripada parsing mesin, pertahankan manifest sebagai kapabilitas tingkat lanjut dan tingkatkan OpenAPI, notifikasi, serta kebijakan versi. Beri label setiap komitmen eksternal dengan status draf dan jaminan kompatibilitas.
Contoh jawaban berkualitas tinggi
Saya akan membangunnya, tetapi memposisikannya sebagai uji coba sinyal siklus hidup tingkat field, bukan sebagai standar yang sudah final. Pelanggan dapat menerima sinyal Deprecation dan Sunset tingkat resource saat ini, namun sinyal tersebut tidak mengidentifikasi anggota response tertentu. Manifest dapat memberi otomatisasi informasi anggota, tanggal, pengganti, dan tautan migrasi.
Fase pertama mendukung satu model response JSON serta tanggal depresiasi dan sunset yang eksplisit. OpenAPI, dokumentasi, dan header tingkat resource tetap menjadi saluran kompatibilitas. Pada saat pendaftaran, platform memvalidasi pemilik anggota, pengganti, dan periode pemberitahuan minimum. Kami mulai dengan API internal dan design partner, mengukur tingkat penemuan, median waktu migrasi, pangsa panggilan anggota yang didepresiasi, false positive, dan rollback. Karena formatnya berasal dari draf IETF Juni 2026, dokumentasi harus menyatakan bahwa format tersebut dapat berubah, dan fitur tersebut memerlukan switch untuk menonaktifkan atau menurunkan versi (downgrade).
Jika uji coba menunjukkan penemuan yang lebih awal dan biaya dukungan yang lebih rendah, perluas ke anggota request dan bentuk yang lebih kompleks. Jika pelanggan mengandalkan dokumentasi daripada parsing, alihkan investasi ke SDK, pemeriksaan CI, dan orkestrasi notifikasi. Keberhasilan berarti lebih sedikit kerusakan tak terduga dan migrasi yang lebih cepat, bukan sekadar menambahkan nama protokol.
Kesalahan umum
- Menyebut Internet-Draft sebagai RFC yang telah disetujui atau menjanjikan dukungan langsung di mana-mana.
- Hanya membahas sintaks JSON tanpa kepemilikan, kebijakan tanggal, notifikasi, dan rollback.
- Mengasumsikan bahwa response header dapat menemukan anggota bersarang arbitrer secara otomatis.
- Hanya memberikan keputusan ya/tidak tanpa uji coba, metrik, dan kondisi penghentian.
- Mengabaikan ambiguitas dari anggota request, indeks array, dan bentuk polimorfik.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika pelanggan tidak mem-parsing manifest?
Pertahankan sebagai pelengkap yang dapat dibaca mesin dan lanjutkan OpenAPI, dokumen migrasi, changelog SDK, webhook, atau pemberitahuan email. Gunakan tingkat penemuan untuk mengukur penggunaan nyata daripada memaksakan adopsi.
Bagaimana Anda menangani perubahan pada draf?
Isolasi generator manifest dari API pelanggan, catat versi format, izinkan penonaktifan manifest atau fallback ke dokumen dan header tingkat resource, serta beri label status draf pada catatan kompatibilitas.
Kapan Anda akan mendukung anggota request?
Hanya setelah uji coba anggota response menunjukkan selektor, tanggal, dan alur kerja migrasi yang stabil, serta anggota request memiliki semantik validasi dan rollback yang jelas. Jika tidak, false positive dapat menjadi operasi penulisan yang gagal.
Bagaimana Anda membuktikan nilai produk?
Bandingkan grup uji coba dan grup kontrol pada waktu penyelesaian migrasi, pangsa panggilan anggota yang didepresiasi, tiket dukungan, dan tingkat rollback. Periksa juga cakupan parser dan false positive; jumlah kunjungan halaman dokumentasi saja tidak membuktikan keberhasilan migrasi.