Kode respon REST untuk data yang tidak valid

Kode respons apa yang harus diberikan kepada klien jika ada skenario berikut?

1. Data yang dikirimkan tidak valid saat pendaftaran pengguna seperti format email yang salah
2. Nama pengguna / Email sudah ada

Saya memilih 403. Saya juga menemukan yang menurut saya bisa digunakan.

Wikipedia:

412 Prasyarat Gagal: Server tidak memenuhi salah satu prasyarat yang diminta pemohon atas permintaan

Sarankan kode jika saya harus menggunakan selain 403.

400 adalah pilihan terbaik dalam kedua kasus. Jika Anda ingin mengklarifikasi kesalahan lebih lanjut, Anda dapat mengubah Frasa Alasan atau menyertakan badan untuk menjelaskan kesalahan tersebut.

412 - Prakondisi gagal digunakan untuk permintaan bersyarat saat menggunakan tanggal modifikasi terakhir dan ETag.

403 - Forbidden digunakan ketika server ingin mencegah akses ke sumber daya.

Satu-satunya pilihan lain yang mungkin adalah 422 - Entitas yang tidak dapat diproses.

Saya akan merekomendasikan 422. Ini bukan bagian dari spesifikasi HTTP utama, tetapi ditentukan oleh standar publik (WebDAV) dan harus diperlakukan oleh browser sama seperti kode status 4xx lainnya.

Dari RFC 4918 :

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 benar (dengan demikian 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.

Jika permintaan tidak dapat diuraikan dengan benar (termasuk entitas / badan permintaan) respons yang sesuai adalah 400 Permintaan Buruk [ 1 ].

RFC 4918 menyatakan bahwa 422 Entitas yang tidak dapat diproses berlaku ketika entitas yang diminta terbentuk dengan baik secara sintaksis, tetapi secara semantik keliru. Jadi, jika entitas permintaan kacau (seperti format email yang buruk) gunakan 400; tetapi jika itu tidak masuk akal (seperti @example.com) gunakan 422.

Jika masalahnya adalah, seperti yang dinyatakan dalam pertanyaan, nama pengguna / email sudah ada, Anda dapat menggunakan 409 Konflik [ 2 ] dengan deskripsi konflik, dan petunjuk tentang cara memperbaikinya (dalam hal ini, "pilih sebuah nama pengguna / email berbeda "). Namun dalam spesifikasi seperti yang tertulis, 403 Forbidden [ 3 ] juga dapat digunakan dalam kasus ini, argumen tentang Otorisasi HTTP.

412 Prekondisi Gagal [ 4 ] digunakan ketika header permintaan prekondisi (mis. If-Match) Yang disediakan oleh klien dievaluasi menjadi false. Artinya, klien meminta sesuatu dan menyediakan prasyarat, mengetahui sepenuhnya bahwa prasyarat itu mungkin gagal. 412 seharusnya tidak pernah muncul pada klien secara tiba-tiba, dan seharusnya tidak terkait dengan entitas permintaan per se .

Sangat menyenangkan untuk kembali 418 I'm a teapotke permintaan yang jelas-jelas dibuat atau berbahaya dan "tidak dapat terjadi", seperti gagal memeriksa CSRF atau kehilangan properti permintaan.

2.3.2 418 Saya seorang teko

Setiap usaha untuk menyeduh kopi dengan teko harus menghasilkan kode kesalahan "418 Saya seorang teko". Badan entitas yang dihasilkan MUNGKIN pendek dan kokoh.

Untuk menjaganya agar tetap serius, saya membatasi penggunaan kode kesalahan lucu untuk titik akhir tenang yang tidak langsung terpapar ke pengguna.