Wawancara Backend: Mengapa 405 Method Not Allowed Wajib Mengembalikan Allow?

Pertanyaan

Anda mengelola sebuah API file: GET /v1/files/:id membaca sebuah file, tetapi klien mengirimkan POST atau DELETE ke sumber daya yang sama. Pewawancara meminta Anda merancang respons dan menjelaskan perbedaan antara 405, 404, 403, OPTIONS, dan preflight CORS. Cakup pencocokan rute (route matching), header Allow, body error, pengujian, dan proses rollout.

Konteks dan batasan

• Rute sumber daya cocok dengan file konkret, tetapi hanya GET dan HEAD yang diaktifkan saat ini.
• Ketidakcocokan versi SDK dapat menyebabkan metode tidak valid, dan proksi mungkin menulis ulang (rewrite) atau mencegatnya.
• Pemanggil memerlukan respons yang dapat didiagnosis, sementara metode yang dinonaktifkan tidak boleh diiklankan sebagai tersedia.
• Jika keberadaan sumber daya bersifat sensitif, tim dapat menggunakan kebijakan penyembunyian 404 yang konsisten, yang didokumentasikan dalam kontrak API.

Apa yang sedang diuji oleh pewawancara

Memisahkan pencocokan sumber daya dari dispatch metode

Cocokkan host, path, versi, dan pengidentifikasi sumber daya terlebih dahulu, lalu cari himpunan metode yang diizinkan untuk sumber daya tersebut. Kembalikan 404 jika path tidak ada; kembalikan 405 jika path ada tetapi metode berada di luar himpunan tersebut. Otorisasi tetap mengikuti kebijakan keamanan: pemanggil terotentikasi tanpa izin dapat menerima 403. Jangan mengubah setiap kegagalan otorisasi menjadi 405.

405 harus menyertakan Allow

405 berarti server mengenali metode permintaan tetapi sumber daya target tidak mendukungnya. Respons wajib menyertakan Allow, yang mencantumkan metode yang saat ini didukung oleh sumber daya tersebut, misalnya:

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS
Content-Type: application/problem+json

{"type":"about:blank","title":"Method Not Allowed","status":405,"detail":"Use one of the methods listed in Allow."}

Allow menjelaskan kemampuan sumber daya. Ini berbeda dari Access-Control-Allow-Methods milik CORS, yang berpartisipasi dalam kebijakan lintas-asal (cross-origin) browser dan tidak dapat menggantikan kontrak metode HTTP yang dinyatakan oleh 405.

Modelkan OPTIONS secara terpisah

OPTIONS dapat menanyakan tentang opsi komunikasi. Preflight CORS browser juga mengirimkan Origin dan Access-Control-Request-Method. Apakah preflight berhasil bergantung pada header respons CORS dan kebijakan otentikasi. Jangan mengubah setiap permintaan OPTIONS menjadi 405, dan jangan memperlakukan Allow sebagai daftar otorisasi CORS.

Pertanyaan klarifikasi sebelum menjawab

• Apakah sumber daya tersebut benar-benar ada? Jika tidak, gunakan 404; jika kebijakan keamanan menyembunyikan keberadaannya, konfirmasikan apakah kebijakan tersebut secara konsisten mengembalikan 404.
• Bisakah metode yang diizinkan bervariasi berdasarkan tenant, status sumber daya, atau versi API? Jawabannya mengubah konteks yang digunakan untuk menghasilkan Allow dan cache key.
• Akankah gateway menulis ulang metode yang tidak dikenal, dan siapa yang mengelola pembuatan Allow? Jawabannya menentukan batasan debugging dan satu-satunya sumber kebenaran (single source of truth).

Kerangka jawaban 30 detik

“Path cocok, tetapi metodenya berada di luar himpunan kemampuan sumber daya, jadi saya mengembalikan 405 dan mencantumkan metode yang benar-benar didukung dalam Allow. Path yang hilang adalah 404, penolakan otorisasi mengikuti kebijakan 403, serta OPTIONS dan preflight CORS menggunakan header terpisah. Saya akan melengkapinya dengan matriks metode, pengujian jalur gateway riil, dan metrik rollout.”

Jawaban mendalam langkah demi langkah

Definisikan metode yang diizinkan untuk setiap rute sumber daya dalam registry yang dapat diaudit, lalu biarkan router menggunakan registry yang sama tersebut untuk dispatch dan pembuatan Allow. Untuk POST /v1/files/123, kembalikan 405 jika sumber daya ada dan POST tidak terdaftar; kembalikan 404 jika 123 tidak ada; kembalikan 403 untuk permintaan yang cocok tetapi ditolak oleh kebijakan otorisasi. HEAD sering kali mengikuti kemampuan baca dari GET, namun perilaku aktual framework adalah sumber kebenarannya.

Body error harus memberikan status yang stabil, judul, dan penjelasan yang dapat ditindaklanjuti tanpa mengekspos stack trace atau detail rute internal. Cantumkan hanya metode yang benar-benar diaktifkan di Allow; selama rollout, jangan mengiklankan kemampuan tulis yang belum dideploy. Jika kebijakan keamanan menyembunyikan keberadaan sumber daya, dokumentasikan pilihan antara 404 versus 405, field log, dan perilaku percobaan ulang (retry) klien.

Contoh jawaban berkualitas tinggi

“Pertama-tama saya akan membiarkan router memastikan apakah file tersebut ada, kemudian melakukan dispatch dari satu registry metode. Untuk file yang ada dan menerima POST yang tidak terdaftar, kembalikan 405 dan sertakan GET, HEAD, ditambah OPTIONS yang benar-benar didukung, di dalam Allow; kembalikan 404 untuk file yang hilang dan ikuti kebijakan otorisasi untuk 403. Preflight CORS menggunakan Access-Control-Allow-Methods, bukan Allow. Gateway dan aplikasi memiliki satu pemilik untuk pembuatan header. Uji kontrak memeriksa setiap status dan himpunan metode, sementara rollout memantau 405 berdasarkan metode.”

Kesalahan umum

• Mengembalikan 404 untuk path yang ada dengan metode yang tidak didukung, membuat pemanggil tidak dapat membedakan antara URL yang salah atau metode yang salah.
• Mengembalikan 405 tanpa Allow, mencegah klien menemukan metode yang didukung dan melanggar semantik HTTP.
• Menggunakan Access-Control-Allow-Methods sebagai pengganti Allow, membingungkan kemampuan HTTP dengan izin lintas-asal (cross-origin) browser.
• Mengubah setiap kegagalan otorisasi menjadi 405, yang merusak audit keamanan, pemantauan, dan perilaku klien.
• Membiarkan gateway dan aplikasi menghasilkan himpunan Allow yang berbeda, menghasilkan respons yang tidak konsisten setelah caching oleh proksi.

Kesalahan, alasan, perbaikan

Memperlakukan 405 sebagai kegagalan umum, menghilangkan Allow, atau menggunakan header CORS sebagai Allow membuat pemanggil tidak memiliki tindakan lanjutan. Perbaiki alur dengan mencocokkan sumber daya terlebih dahulu, menghasilkan status dan header dari satu registry metode, serta menguji 404, 403, 405, dan preflight secara terpisah.

Implementasi produksi

Mengoordinasikan rute dan proksi

Teruskan 405 dan Allow dari aplikasi melalui gateway atau tentukan satu pemilik di gateway dan cegah penimpaan ganda. Kelola matriks metode per versi API, termasuk persyaratan caching, idempotensi, otentikasi, dan retry. Jika proksi menurunkan (downgrade) metode yang tidak dikenal menjadi GET, perbaiki kebijakan tersebut terlebih dahulu; jika tidak, aplikasi tidak akan pernah melihat metode yang sebenarnya.

Keteramatan dan kompatibilitas

Catat metode permintaan, path yang dinormalisasi, versi rute, status respons, dan himpunan akhir Allow tanpa mencatat konten file. Setelah menerima 405, klien harus berhenti mencoba ulang metode yang sama secara membabi buta dan beralih menggunakan metode yang didukung kontrak atau memperbarui SDK-nya. Untuk klien lama (legacy), amati penggunaan yang salah di log dan dokumentasi sebelum memperketat perilaku melalui perubahan berversi.

Daftar periksa verifikasi

Uji kontrak

Bangun matriks metode untuk setiap sumber daya yang mencakup: keberhasilan untuk metode terdaftar, 405 untuk metode tidak terdaftar, 404 untuk path yang hilang, 403 untuk penolakan otorisasi, dan kesesuaian antara Allow dan rute sebenarnya. Lakukan assertion pada status, himpunan metode header, content type, dan field body error.

Integrasi dan regresi

Gunakan klien HTTP riil untuk memverifikasi perilaku gateway, load balancer, dan aplikasi secara bersamaan. Uji OPTIONS dan preflight CORS secara terpisah, memastikan bahwa Access-Control-Allow-Methods tidak menggantikan Allow. Selama rollout, pasang peringatan (alert) pada tingkat error 405, distribusi metode, dan kegagalan parsing body error.

Pertanyaan lanjutan dan tanggapan

Kapan 404 dapat dikembalikan alih-alih 405?

Kembalikan 404 ketika path benar-benar tidak ada atau ketika kebijakan keamanan secara sengaja menyembunyikan keberadaan sumber daya. Terapkan pilihan tersebut secara konsisten untuk kelas sumber daya tersebut dan dokumentasikan untuk klien, log, dan pemantauan; node yang berbeda tidak boleh secara acak mengembalikan 404 atau 405.

Haruskah Allow selalu menyertakan OPTIONS?

Sertakan hanya jika sumber daya benar-benar menerima OPTIONS. Jika framework menangani OPTIONS secara otomatis, verifikasi bahwa responsnya cocok dengan kontrak rute aplikasi; jangan menambahkan metode yang belum diimplementasikan hanya demi kelengkapan visual.

Bagaimana kemampuan dinamis seharusnya bekerja?

Ketika kemampuan metode bervariasi berdasarkan tenant, versi, atau status sumber daya, hasilkan Allow dari konteks permintaan saat ini dan sertakan semua dimensi kemampuan dalam cache key. Default yang lebih aman adalah membatasi caching perantara untuk 405 atau menetapkan kebijakan cache yang eksplisit.

Rubrik penilaian

• Akurasi semantik: menjelaskan kapan 405 berlaku dan mengapa Allow wajib disertakan.
• Batasan yang jelas: membedakan 404, 403, OPTIONS, CORS, dan penyembunyian keamanan.
• Implementasi praktis: memberikan pilihan konkret terkait registry, proksi, body error, dan observabilitas.
• Verifikasi lengkap: mencakup matriks metode, jalur HTTP riil, metrik rollout, dan regresi.
• Kesadaran risiko: menghindari pengiklanan metode palsu, kebocoran informasi, dan perbedaan (drift) antara gateway/aplikasi.

Referensi

• MDN: 405 Method Not Allowed
• MDN: Allow header
• Postman: HTTP Error 405
• JustAcademy: REST API interview questions

Tips menjawab

Mulailah dengan “sumber daya cocok, metode tidak didukung, kembalikan 405,” kemudian berikan himpunan Allow yang sebenarnya. Bedakan 404, 403, OPTIONS, dan CORS, lalu akhiri dengan pengujian matriks metode dan konsistensi proksi.

Poin penting dalam satu kalimat

405 menyatakan bahwa kombinasi sumber daya-metode tidak valid, sedangkan Allow memberi tahu klien metode mana yang saat ini valid; keduanya bersama-sama membentuk kontrak HTTP yang dapat didiagnosis.