Temu Duga Backend: Mengapa 405 Method Not Allowed Mesti Mengembalikan Allow?

Soalan

Anda menyelenggara API fail: GET /v1/files/:id membaca fail, tetapi klien menghantar POST atau DELETE kepada sumber yang sama. Penemu duga meminta anda mereka bentuk respons dan menerangkan perbezaan antara 405, 404, 403, OPTIONS, dan pra-penerbangan CORS. Rangkumi pemadanan laluan, pengepala Allow, badan ralat, ujian, dan peluncuran (rollout).

Konteks dan kekangan

• Laluan sumber sepadan dengan fail konkrit, tetapi hanya GET dan HEAD yang didayakan hari ini.
• Ketakpadanan versi SDK mungkin menyebabkan kaedah tidak sah, dan proksi mungkin menulis semula atau memintasnya.
• Pemanggil memerlukan respons yang boleh didiagnosis, manakala kaedah yang dinyahdayakan tidak boleh diiklankan sebagai tersedia.
• Jika kewujudan sumber adalah sensitif, pasukan boleh menggunakan dasar penyembunyian 404 yang konsisten, yang didokumenkan dalam kontrak API.

Perkara yang diuji oleh penemu duga

Asingkan pemadanan sumber daripada penghantaran kaedah

Padankan hos, laluan, versi, dan pengecam sumber terlebih dahulu, kemudian cari set kaedah yang dibenarkan untuk sumber tersebut. Kembalikan 404 apabila laluan tiada; kembalikan 405 apabila laluan wujud tetapi kaedah berada di luar set tersebut. Kebenaran (authorization) masih mengikut dasar keselamatan: pemanggil yang disahkan tanpa kebenaran mungkin menerima 403. Jangan ubah setiap kegagalan kebenaran menjadi 405.

405 mesti menyertakan Allow

405 bermaksud pelayan mengenali kaedah permintaan tetapi sumber sasaran tidak menyokongnya. Respons mesti menyertakan Allow, menyenaraikan kaedah yang kini disokong oleh sumber tersebut, contohnya:

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 menerangkan keupayaan sumber. Ia berbeza daripada Access-Control-Allow-Methods milik CORS, yang mengambil bahagian dalam dasar silang asal pelayar dan tidak boleh menggantikan kontrak kaedah HTTP yang dinyatakan oleh 405.

Modelkan OPTIONS secara berasingan

OPTIONS boleh bertanya tentang pilihan komunikasi. Pra-penerbangan CORS pelayar juga menghantar Origin dan Access-Control-Request-Method. Sama ada pra-penerbangan berjaya bergantung pada pengepala respons CORS dan dasar pengesahan. Jangan ubah setiap permintaan OPTIONS menjadi 405, dan jangan anggap Allow sebagai senarai kebenaran CORS.

Soalan penjelasan sebelum menjawab

• Adakah sumber tersebut benar-benar wujud? Jika tidak, gunakan 404; jika dasar keselamatan menyembunyikan kewujudan, sahkan sama ada ia mengembalikan 404 secara konsisten.
• Bolehkah kaedah yang dibenarkan berbeza mengikut penyewa (tenant), keadaan sumber, atau versi API? Jawapannya mengubah konteks yang digunakan untuk menjana Allow dan kunci cache.
• Adakah get laluan akan menulis semula kaedah yang tidak diketahui, dan siapakah pemilik penjanaan Allow? Jawapannya mentakrifkan sempadan penyahpepijatan dan punca kebenaran tunggal (single source of truth).

Rangka kerja jawapan 30 saat

“Laluan dipadankan, tetapi kaedah berada di luar set keupayaan sumber, jadi saya mengembalikan 405 dan menyenaraikan kaedah yang benar-benar disokong dalam Allow. Laluan yang hilang ialah 404, penafian kebenaran mengikut dasar 403, dan OPTIONS serta pra-penerbangan CORS menggunakan pengepala berasingan. Saya akan akhiri dengan matriks kaedah, ujian laluan get laluan sebenar, dan metrik peluncuran.”

Jawapan mendalam langkah demi langkah

Takrifkan kaedah yang dibenarkan bagi setiap laluan sumber dalam pendaftaran yang boleh diaudit, kemudian biarkan penghala menggunakan pendaftaran yang sama untuk penghantaran dan penjanaan Allow. Untuk POST /v1/files/123, kembalikan 405 jika sumber wujud dan POST tidak didaftarkan; kembalikan 404 jika 123 tidak wujud; kembalikan 403 untuk permintaan yang dipadankan tetapi dinafikan oleh dasar kebenaran. HEAD sering kali mengikut keupayaan boleh dibaca bagi GET, tetapi tingkah laku sebenar rangka kerja adalah punca kebenaran.

Badan ralat harus menyediakan status yang stabil, tajuk, dan penjelasan yang boleh diambil tindakan tanpa mendedahkan surih tindanan (stack traces) atau butiran laluan dalaman. Senaraikan hanya kaedah yang benar-benar didayakan dalam Allow; semasa peluncuran, jangan iklankan keupayaan tulis yang belum digunakan. Jika dasar keselamatan menyembunyikan kewujudan sumber, dokumentasikan pilihannya antara 404 dan 405, medan log, dan tingkah laku percubaan semula klien.

Contoh jawapan berkualiti tinggi

“Saya akan terlebih dahulu membiarkan penghala menentukan sama ada fail itu wujud, kemudian menghantar daripada satu pendaftaran kaedah. Bagi fail sedia ada yang menerima POST yang tidak didaftarkan, kembalikan 405 dan letakkan GET, HEAD, ditambah dengan OPTIONS yang benar-benar disokong, dalam Allow; kembalikan 404 untuk fail yang tiada dan ikuti dasar kebenaran untuk 403. Pra-penerbangan CORS menggunakan Access-Control-Allow-Methods, bukan Allow. Get laluan dan aplikasi mempunyai satu pemilik untuk penjanaan pengepala. Ujian kontrak memeriksa setiap status dan set kaedah, manakala peluncuran memantau 405 mengikut kaedah.”

Kesilapan biasa

• Mengembalikan 404 untuk laluan sedia ada dengan kaedah yang tidak disokong, menyebabkan pemanggil tidak dapat membezakan URL yang salah daripada kaedah yang salah.
• Mengembalikan 405 tanpa Allow, menghalang klien daripada mengetahui kaedah yang disokong dan melanggar semantik HTTP.
• Menggunakan Access-Control-Allow-Methods menggantikan Allow, mengelirukan keupayaan HTTP dengan kebenaran silang asal pelayar.
• Menukar setiap kegagalan kebenaran kepada 405, yang merosakkan audit keselamatan, pemantauan, dan tingkah laku klien.
• Membiarkan get laluan dan aplikasi menjana set Allow yang berbeza, menghasilkan respons yang tidak konsisten selepas caching proksi.

Ralat, sebab, pembetulan

Menganggap 405 sebagai kegagalan generik, meninggalkan Allow, atau menggunakan pengepala CORS sebagai Allow menyebabkan pemanggil tiada tindakan seterusnya. Betulkan aliran dengan memadankan sumber terlebih dahulu, menjana status dan pengepala daripada satu pendaftaran kaedah, dan menguji 404, 403, 405, serta pra-penerbangan secara berasingan.

Pelaksanaan pengeluaran

Selaraskan laluan dan proksi

Sama ada salurkan 405 dan Allow aplikasi melalui get laluan atau takrifkan satu pemilik get laluan dan elakkan penulisan ganti pendua. Kekalkan matriks kaedah bagi setiap versi API, termasuk keperluan caching, idempotensi, pengesahan, dan percubaan semula. Jika proksi menurunkan taraf kaedah yang tidak diketahui kepada GET, betulkan dasar itu terlebih dahulu; jika tidak, aplikasi tidak akan melihat kaedah sebenar.

Kebolehmerhatian dan keserasian

Log kaedah permintaan, laluan dinormalisasi, versi laluan, status respons, dan set akhir Allow tanpa melog kandungan fail. Selepas menerima 405, klien harus berhenti mencuba semula kaedah yang sama secara membuta tuli dan menggunakan kaedah yang disokong kontrak atau menaik taraf SDK-nya. Bagi klien legasi, perhatikan penyalahgunaan dalam log dan dokumentasi sebelum mengetatkan tingkah laku melalui perubahan berversi.

Senarai semak pengesahan

Ujian kontrak

Bina matriks kaedah untuk setiap sumber yang merangkumi: kejayaan untuk kaedah yang didaftarkan, 405 untuk kaedah yang tidak didaftarkan, 404 untuk laluan yang tiada, 403 untuk penafian kebenaran, dan kesamaan antara Allow dan laluan sebenar. Sahkan status, set kaedah pengepala, jenis kandungan, dan medan badan ralat.

Integrasi dan regresi

Gunakan klien HTTP sebenar untuk mengesahkan tingkah laku get laluan, pengimbang beban, dan aplikasi secara bersama. Uji OPTIONS dan pra-penerbangan CORS secara berasingan, mengesahkan bahawa Access-Control-Allow-Methods tidak menggantikan Allow. Semasa peluncuran, tetapkan amaran pada kadar 405, pengedaran kaedah, dan kegagalan penghuraian badan ralat.

Soalan susulan dan respons

Bilakah 404 boleh dikembalikan dan bukannya 405?

Kembalikan 404 apabila laluan benar-benar tidak wujud atau apabila dasar keselamatan sengaja menyembunyikan kewujudan sumber. Gunakan pilihan tersebut secara konsisten untuk kelas sumber dan dokumentasikannya untuk klien, log, dan pemantauan; nod yang berbeza tidak sepatutnya mengembalikan 404 atau 405 secara rawak.

Adakah Allow mesti sentiasa menyertakan OPTIONS?

Sertakannya hanya apabila sumber benar-benar menerima OPTIONS. Jika rangka kerja mengendalikan OPTIONS secara automatik, sahkan bahawa responsnya sepadan dengan kontrak laluan aplikasi; jangan tambah kaedah yang tidak dilaksanakan semata-mata untuk kesempurnaan visual.

Bagaimanakah keupayaan dinamik sepatutnya berfungsi?

Apabila keupayaan kaedah berbeza mengikut penyewa, versi, atau keadaan sumber, jana Allow daripada konteks permintaan semasa dan sertakan semua dimensi keupayaan dalam kunci cache. Pilihan lalai yang lebih selamat adalah mengehadkan caching perantara untuk 405 atau menetapkan dasar cache yang jelas.

Rubrik pemarkahan

• Ketepatan semantik: menerangkan bila 405 terpakai dan mengapa Allow adalah wajib.
• Sempadan yang jelas: membezakan 404, 403, OPTIONS, CORS, dan penyembunyian keselamatan.
• Pelaksanaan praktikal: memberikan pilihan konkrit mengenai pendaftaran, proksi, badan ralat, dan kebolehmerhatian.
• Pengesahan lengkap: merangkumi matriks kaedah, laluan HTTP sebenar, metrik peluncuran, dan regresi.
• Kesedaran risiko: mengelakkan pengiklanan kaedah palsu, kebocoran maklumat, dan hanyutan (drift) antara get laluan/aplikasi.

Rujukan

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

Petua menjawab

Mulakan dengan “sumber dipadankan, kaedah tidak disokong, kembalikan 405,” kemudian berikan set Allow yang sebenar. Bezakan 404, 403, OPTIONS, dan CORS, serta akhiri dengan ujian matriks kaedah dan ketekalan proksi.

Pengajaran satu ayat

405 menyatakan bahawa gabungan sumber-kaedah tidak sah, manakala Allow memberitahu klien kaedah mana yang sah pada masa ini; bersama-sama mereka membentuk kontrak HTTP yang boleh didiagnosis.