Kode status HTTP kanan ke input yang salah

Apakah kode respons HTTP optimal ketika tidak melaporkan 200 (semuanya OK) tetapi kesalahan dalam input?

Seperti, Anda mengirimkan beberapa data ke server, dan itu akan menjawab bahwa data Anda salah

menggunakan 500lebih mirip Server Issue
menggunakan 200dengan peringatan / teks respons kesalahan buruk (memungkinkan caching dan semuanya tidak OK)
menggunakan 204dan mengembalikan apa-apa, apakah mungkin baik (tetapi didukung dengan baik?)
menggunakan 404salah jika jalur yang diminta (skrip) tersedia dan di tempat yang tepat

Kami memiliki masalah yang sama saat membuat API kami juga. Kami sedang mencari kode status HTTP yang setara dengan InvalidArgumentException. Setelah membaca artikel sumber di bawah ini, kami akhirnya menggunakan 422 Unprocessable Entityyang menyatakan:

Kode status 422 (Entitas yang Tidak Dapat Diproses) berarti server memahami jenis konten entitas permintaan (oleh karena itu kode status 415 (Jenis Media yang Tidak Didukung) tidak pantas), dan sintaks entitas permintaan tersebut benar (sehingga 400 (Permintaan Buruk) ) kode status tidak pantas) tetapi tidak dapat memproses instruksi yang terkandung. Misalnya, kondisi kesalahan ini dapat terjadi jika badan permintaan XML berisi formulasi XML yang baik (yaitu, benar secara sintaksis), tetapi secara semestinya salah.

sumber: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm

Kode yang dimulai dengan 4 (4xx) dimaksudkan untuk kesalahan klien. Mungkin 400 (Permintaan Buruk) bisa cocok untuk kasus ini? Definisi dalam http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html mengatakan:

"Permintaan tidak dapat dipahami oleh server karena sintaksis cacat. Klien TIDAK HARUS mengulangi permintaan tanpa modifikasi."

Selain Spesifikasi RFC Anda juga dapat melihat ini dalam tindakan. Lihat tanggapan twitter.

https://developer.twitter.com/en/docs/ads/general/guides/response-codes

409 Conflict bisa menjadi solusi yang bisa diterima.

Berdasarkan: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Permintaan tidak dapat diselesaikan karena konflik dengan kondisi sumber daya saat ini. Kode ini hanya diperbolehkan dalam situasi di mana diharapkan pengguna mungkin dapat menyelesaikan konflik dan mengirim kembali permintaan. Badan respons HARUS menyertakan informasi yang cukup bagi pengguna untuk mengenali sumber konflik. Idealnya, entitas respons akan mencakup informasi yang cukup bagi pengguna atau agen pengguna untuk memperbaiki masalah; Namun, itu mungkin tidak mungkin dan tidak diperlukan.

Doc melanjutkan dengan sebuah contoh:

Konflik kemungkinan besar terjadi sebagai respons terhadap permintaan PUT. Misalnya, jika versi sedang digunakan dan entitas yang PUT menyertakan perubahan ke sumber daya yang bertentangan dengan yang dibuat oleh permintaan sebelumnya (pihak ketiga), server mungkin menggunakan respons 409 untuk menunjukkan bahwa ia tidak dapat menyelesaikan permintaan . Dalam hal ini, entitas respons kemungkinan akan berisi daftar perbedaan antara dua versi dalam format yang ditentukan oleh Tipe Konten respons.

Dalam kasus saya, saya ingin PUT string, yang harus unik, ke database melalui API. Sebelum menambahkannya ke database, saya memeriksa bahwa itu belum ada dalam database.

Jika ya, saya akan kembali "Error: The string is already in the database", 409 .

Saya percaya inilah yang diinginkan OP: kode kesalahan cocok untuk ketika data tidak lulus kriteria server.

Menurut skenario di bawah ini,

Katakanlah seseorang membuat permintaan ke server Anda dengan data yang dalam format yang benar, tetapi sama sekali bukan data "baik". Jadi misalnya, bayangkan bahwa seseorang memposting nilai String ke titik akhir API yang mengharapkan nilai String; tetapi, nilai string berisi data yang dimasukkan dalam daftar hitam (mis. mencegah orang menggunakan "kata sandi" sebagai kata sandi mereka). maka kode status bisa berupa 400 atau 422?

Sampai sekarang, saya akan mengembalikan "400 Permintaan Buruk", yang, menurut w3.org, berarti:

Permintaan tidak dapat dipahami oleh server karena sintaksis yang salah. Klien TIDAK HARUS mengulangi permintaan tanpa modifikasi.

Deskripsi ini tidak sesuai dengan keadaan; tetapi, jika Anda melihat daftar kode status HTTP inti yang didefinisikan dalam protokol HTTP / 1.1, itu mungkin pilihan terbaik Anda.

Namun baru-baru ini, seseorang dari tim Dev saya menunjukkan [kepada saya] bahwa API populer mulai menggunakan ekstensi HTTP untuk mendapatkan lebih banyak rincian dengan pelaporan kesalahan mereka. Secara khusus, banyak API, seperti Twitter dan Recurly, menggunakan kode status "422 Entitas yang Tidak Dapat Diproses" sebagaimana didefinisikan dalam ekstensi HTTP untuk WebDAV. Kode status HTTP 422 menyatakan:

Kode status 422 (Entitas yang Tidak Dapat Diproses) berarti server memahami jenis konten entitas permintaan (oleh karena itu kode status 415 (Jenis Media yang Tidak Didukung) tidak pantas), dan sintaks entitas permintaan tersebut benar (sehingga 400 (Permintaan Buruk) ) kode status tidak pantas) tetapi tidak dapat memproses instruksi yang terkandung. Misalnya, kondisi kesalahan ini dapat terjadi jika badan permintaan XML berisi formulasi XML yang baik (yaitu, benar secara sintaksis), tetapi secara semestinya salah.

Kembali ke contoh kata sandi kami dari atas, kode status 422 ini terasa jauh lebih tepat. Server memahami apa yang Anda coba lakukan; dan ia memahami data yang Anda kirim; itu tidak akan membiarkan data diproses.

404 - Tidak Ditemukan - dapat digunakan untuk URI yang diminta tidak valid atau sumber daya yang diminta seperti pengguna, tidak ada.