Kode respon REST untuk data yang tidak valid

272

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

Data yang dikirimkan tidak valid saat pendaftaran pengguna seperti format email yang salah
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.

http rest jax-rs

— Amit Patel
sumber

Kemungkinan rangkap: stackoverflow.com/questions/3050518/…

— Genjo

Saya menyelesaikan masalah ini juga. Bab 7.Validation JAX-RS spec (2017) memberikan saran kode status khusus untuk pelanggaran kendala. download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-spec/...

— burntsugar

298

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.

— Darrel Miller
sumber

10

sementara itu sering digunakan dalam konteks ini, 403 tidak terbatas pada kontrol acces, karena rfc2616-10.4.4 mengatakan: "Server memahami permintaan, tetapi menolak untuk memenuhinya. [...] jika server ingin membuat publik mengapa permintaan belum dipenuhi, itu HARUS menggambarkan alasan penolakan dalam entitas. " Alasannya bisa data tidak valid. Namun, 422 lebih berlaku di sini.

— Yannick Loiseau

7

Jangan terjebak dalam kritik teks. Lihat misalnya trac.tools.ietf.org/wg/httpbis/trac/ticket/294 yang mencoba menjelaskan bahwa 403 adalah dan selalu tentang otorisasi.

— fumanchu

2

@fumanchu Tangkapan bagus. Tautan ke permintaan perubahan yang baru berusia 7 jam :-)

— Darrel Miller

1

@fumanchu Ini berarti 403 harus dikembalikan jika pengguna tidak memiliki izin untuk mengakses sumber daya yang diminta. Tapi saya pikir 401 Unauthorized lebih tepat untuk mengakses sumber daya di mana pengguna tidak memiliki izin.

— Amit Patel

1

401 Tidak Sah akan meminta browser web untuk menampilkan kepada pengguna permintaan HTTP standar / nama pengguna / kata sandi. Jika Anda tidak menggunakan otentikasi semacam itu untuk layanan Anda, atau jika pengguna sudah memiliki otentikasi HTTP, 401 tidak tepat.

— Greg Ball

92

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.

— Mike Deck
sumber

20

Perhatikan bahwa teks yang dikutip menyatakan bahwa 422 berlaku ketika entitas permintaan secara sintaksis terbentuk dengan baik, tetapi secara semantik keliru. Jika entitas permintaan kacau, 400 adalah respons yang sesuai.

— Matty K

87

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 .

— Matty K
sumber

1

Saya harus mencatat HTTP / 1.1 RFC yang diperbarui: 400 Permintaan Buruk, 409 Konflik, 403 Dilarang, dll. Tinggal di tools.ietf.org/html/rfc7231 ; 412 Prasyarat Gagal ada di tools.ietf.org/html/rfc7232#s-4-4

— Matty K

41

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.

— doug65536
sumber

11

Terapkan itu sedemikian rupa sehingga API Anda kembali 418 I'm a teapotuntuk semua permintaan yang datang dari bos Anda :)

— vikarjramun

2

@vikarjramun saya membuat REST boneka dan menjadikannya pruductive secara offline. (prerelease) sekarang siswa kami sedang mencari mencoba membuat permintaan data yang valid tetapi semuanya teko. Saya adalah "bos" - tetapi itu bekerja juga.

— LenglBoy

2

RFC ini bodoh. Anda bisa membuat kopi dalam teko teh, selama Anda menuangkannya melalui saringan teh ke dalam cangkir Anda. Sama seperti menggunakan teh daun longgar. Anda juga dapat membuat teh di kafetaria tanpa masalah.

— gburton

2

@gburton Itu memang membutuhkan intervensi manusia. Melalui jaringan, Anda pasti membutuhkan perangkat yang mampu membuat kopi. Tentu saja, teko kopi dan teh tidak boleh merespons dengan 418.

— Jasper