400 vs 422 respons terhadap POST data

Saya mencoba mencari tahu apa kode status yang benar untuk dikembalikan pada skenario yang berbeda dengan API "seperti REST" yang sedang saya kerjakan. Katakanlah saya memiliki titik akhir yang memungkinkan pembelian POST dalam format JSON. Ini terlihat seperti ini:

{
    "account_number": 45645511,
    "upc": "00490000486",
    "price": 1.00,
    "tax": 0.08
}

Apa yang harus saya kembalikan jika klien mengirimi saya "sales_tax" (bukan "pajak" yang diharapkan). Saat ini, saya mengembalikan 400. Tapi, saya mulai mempertanyakan diri saya sendiri tentang ini. Haruskah saya benar-benar mengembalikan 422? Maksudku, ini JSON (yang didukung) dan JSON yang valid, hanya saja tidak berisi semua bidang yang diperlukan.

400 Permintaan Buruk sekarang tampaknya menjadi kode status HTTP / 1.1 terbaik untuk kasus penggunaan Anda.

Pada saat pertanyaan Anda (dan jawaban asli saya), RFC 7231 bukanlah sesuatu; pada titik mana saya keberatan 400 Bad Requestkarena RFC 2616 berkata (dengan penekanan pada saya):

Permintaan tidak dapat dipahami oleh server karena sintaksis yang salah .

dan permintaan yang Anda jelaskan adalah JSON yang secara sintaksis valid, terbungkus dalam HTTP yang secara sintaksis valid, dan dengan demikian server tidak memiliki masalah dengan sintaksis permintaan.

Namun seperti yang ditunjukkan oleh Lee Saferite dalam komentar , RFC 7231, yang usang RFC 2616, tidak termasuk batasan itu :

Kode status 400 (Permintaan Buruk) menunjukkan bahwa server tidak dapat atau tidak akan memproses permintaan karena sesuatu yang dianggap sebagai kesalahan klien (misalnya, sintaks permintaan salah bentuk, pembingkaian pesan permintaan tidak valid, atau perutean permintaan yang menipu).

Namun, sebelum itu ulang kata-kata (atau jika Anda ingin berdalih tentang RFC 7231 hanya menjadi standar yang diusulkan saat ini), 422 Unprocessable Entitysepertinya kode status HTTP tidak salah untuk kasus penggunaan Anda, karena seperti kata pengantar RFC 4918 mengatakan:

Sementara kode status yang disediakan oleh HTTP / 1.1 cukup untuk menggambarkan sebagian besar kondisi kesalahan yang ditemui oleh metode WebDAV, ada beberapa kesalahan yang tidak termasuk dalam kategori yang ada. Spesifikasi ini mendefinisikan kode status tambahan yang dikembangkan untuk metode WebDAV (Bagian 11)

Dan deskripsi422 kata:

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.

(Perhatikan referensi sintaksis; saya menduga 7231 juga sebagian 4918)

Ini terdengar persis seperti situasi Anda, tetapi kalau-kalau ada keraguan, ia melanjutkan dengan mengatakan:

Sebagai contoh, kondisi kesalahan ini dapat terjadi jika badan permintaan XML berisi formulasi XML yang baik (yaitu, benar secara sintaksis), tetapi secara semestinya salah.

(Ganti "XML" dengan "JSON" dan saya pikir kami dapat menyetujui itu adalah situasi Anda)

Sekarang, beberapa orang akan keberatan bahwa RFC 4918 adalah tentang "Ekstensi HTTP untuk Web Authorized and Versioning (WebDAV)" dan bahwa Anda (mungkin) tidak melakukan apa pun yang melibatkan WebDAV sehingga tidak boleh menggunakan hal-hal dari itu.

Mengingat pilihan antara menggunakan kode kesalahan dalam standar asli yang secara eksplisit tidak mencakup situasi, dan satu dari ekstensi yang menggambarkan situasi dengan tepat, saya akan memilih yang terakhir.

Lebih jauh, RFC 4918 Bagian 21.4 merujuk pada Registri Kode Status IANA Hypertext Transfer Protocol (HTTP) , di mana 422 dapat ditemukan.

Saya mengusulkan bahwa sangat masuk akal bagi klien HTTP atau server untuk menggunakan kode status apa pun dari registri itu, selama mereka melakukannya dengan benar.

Tetapi pada HTTP / 1.1, RFC 7231 memiliki daya tarik, jadi gunakan saja 400 Bad Request!

400 Bad Request adalah kode status HTTP yang tepat untuk kasus penggunaan Anda. Kode ini didefinisikan oleh HTTP / 0.9-1.1 RFC.

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

http://tools.ietf.org/html/rfc2616#section-10.4.1

422 Entitas yang tidak dapat diproses didefinisikan oleh RFC 4918 - WebDav. Perhatikan bahwa ada sedikit perbedaan dibandingkan dengan 400, lihat kutipan teks di bawah ini.

Kondisi kesalahan ini dapat terjadi jika badan permintaan XML berisi formulasi XML yang baik (mis., Benar secara sintaksis), tetapi secara semu salah.

Untuk menjaga antarmuka yang seragam, Anda harus menggunakan 422 hanya dalam kasus respons XML dan Anda juga harus mendukung semua kode status yang ditentukan oleh ekstensi Webdav, bukan hanya 422.

http://tools.ietf.org/html/rfc4918#page-78

Lihat juga pos Mark Nottingham pada kode status:

Adalah suatu kesalahan untuk mencoba memetakan setiap bagian dari aplikasi Anda “secara mendalam” ke dalam kode status HTTP; dalam banyak kasus tingkat granularity yang ingin Anda tuju jauh lebih kasar. Jika ragu, boleh saja menggunakan kode status umum 200 OK, 400 Permintaan Buruk, dan 500 Kesalahan Servis Internal ketika tidak ada kesesuaian yang lebih baik .

Cara Berpikir Tentang Kode Status HTTP

Untuk mencerminkan status pada 2015:

Secara umum kode respons 400 dan 422 akan diperlakukan sama oleh klien dan perantara, sehingga sebenarnya tidak membuat perbedaan nyata yang Anda gunakan.

Namun saya berharap melihat 400 saat ini digunakan secara lebih luas, dan lebih jauh lagi klarifikasi yang disediakan oleh spec HTTPbis menjadikannya lebih sesuai untuk dua kode status:

• HTTPbis spec memperjelas maksud 400 untuk tidak semata-mata karena kesalahan sintaksis. Ungkapan yang lebih luas "menunjukkan bahwa server tidak dapat atau tidak akan memproses permintaan karena sesuatu yang dianggap sebagai kesalahan klien" sekarang digunakan.
• 422 Khususnya adalah ekstensi WebDAV, dan tidak dirujuk dalam RFC 2616 atau dalam spesifikasi HTTPbis yang lebih baru .

Untuk konteks, HTTPbis adalah revisi dari spesifikasi HTTP / 1.1 yang mencoba untuk mengklarifikasi area yang tidak jelas atau tidak konsisten. Setelah mencapai status yang disetujui itu akan menggantikan RFC2616.

Studi kasus: GitHub API

https://developer.github.com/v3/#client-errors

Mungkin menyalin dari API yang terkenal adalah ide yang bijaksana:

Ada tiga jenis kesalahan klien pada panggilan API yang menerima badan permintaan:

Mengirim JSON yang tidak valid akan menghasilkan respons 400 Permintaan Buruk.

HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

Mengirim jenis nilai JSON yang salah akan menghasilkan respons 400 Permintaan Buruk.

HTTP/1.1 400 Bad Request
Content-Length: 40

{"message":"Body should be a JSON object"}

Mengirim bidang yang tidak valid akan menghasilkan respons 422 Entitas yang Tidak Dapat Diproses.

HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

{
  "message": "Validation Failed",
  "errors": [
    {
      "resource": "Issue",
      "field": "title",
      "code": "missing_field"
    }
  ]
}

Tidak ada jawaban yang benar, karena itu tergantung pada definisi "sintaks" untuk permintaan Anda. Yang paling penting adalah Anda:

1. Gunakan kode respons secara konsisten
2. Masukkan sebanyak mungkin informasi tambahan di badan respons untuk membantu pengembang menggunakan API Anda mengetahui apa yang terjadi. =

Sebelum semua orang melompati saya karena mengatakan bahwa tidak ada jawaban benar atau salah di sini, izinkan saya menjelaskan sedikit tentang bagaimana saya sampai pada kesimpulan.

Dalam contoh khusus ini, pertanyaan OP adalah tentang permintaan JSON yang berisi kunci berbeda dari yang diharapkan. Sekarang, nama kunci yang diterima sangat mirip, dari sudut pandang bahasa alami, dengan kunci yang diharapkan, tetapi, secara ketat, berbeda, dan karenanya tidak (biasanya) dikenali oleh mesin sebagai setara.

Seperti yang saya katakan di atas, faktor penentu adalah apa yang dimaksud dengan sintaks . Jika permintaan dikirim dengan Tipe Konten application/json, maka ya, permintaan tersebut secara sintaksis valid karena itu sintaks JSON yang valid, tetapi tidak secara semantik berlaku, karena tidak sesuai dengan yang diharapkan. (dengan asumsi definisi yang ketat tentang apa yang membuat permintaan tersebut valid secara semantik atau tidak).

Jika, di sisi lain, permintaan tersebut dikirim dengan Jenis Konten khusus yang lebih spesifik seperti application/vnd.mycorp.mydatatype+jsonitu, mungkin, menentukan dengan tepat bidang apa yang diharapkan, maka saya akan mengatakan bahwa permintaan tersebut dapat dengan mudah tidak valid secara sintaksis, karenanya tanggapan 400.

Dalam kasus yang dimaksud, karena kunci salah, bukan nilainya , ada kesalahan sintaksis jika ada spesifikasi untuk kunci apa yang valid. Jika tidak ada spesifikasi untuk kunci yang valid, atau kesalahan dengan nilai , maka itu akan menjadi kesalahan semantik .

422 Entitas yang Tidak Dapat Diproses Dijelaskan Diperbarui: 6 Maret 2017

Apa itu 422 Entitas yang Tidak Dapat Diproses?

Kode status 422 terjadi ketika permintaan terbentuk dengan baik, namun karena kesalahan semantik tidak dapat diproses. Status HTTP ini diperkenalkan di RFC 4918 dan lebih khusus diarahkan pada ekstensi HTTP untuk Webing Authoring and Versioning (WebDAV).

Ada beberapa kontroversi di luar sana tentang apakah pengembang harus mengembalikan kesalahan 400 vs 422 kepada klien (lebih lanjut tentang perbedaan antara kedua status di bawah). Namun, dalam kebanyakan kasus, disepakati bahwa status 422 hanya akan dikembalikan jika Anda mendukung kemampuan WebDAV.

Definisi kata demi kata dari kode status 422 yang diambil dari bagian 11.2 dalam RFC 4918 dapat dibaca di bawah ini.

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.

Definisi selanjutnya mengatakan:

Sebagai contoh, kondisi kesalahan ini dapat terjadi jika badan permintaan XML berisi formulasi XML yang baik (yaitu, benar secara sintaksis), tetapi secara semestinya salah.

400 vs 422 Kode Status

Kesalahan permintaan yang buruk menggunakan kode status 400 dan harus dikembalikan ke klien jika sintaks permintaan salah, berisi framing pesan permintaan yang tidak valid, atau memiliki perutean permintaan yang menipu. Kode status ini mungkin tampak sangat mirip dengan status entitas 422 yang tidak dapat diproses, namun, satu informasi kecil yang membedakan mereka adalah fakta bahwa sintaks entitas permintaan untuk kesalahan 422 adalah benar sedangkan sintaks permintaan yang menghasilkan 400 kesalahan salah.

Penggunaan status 422 harus dicadangkan hanya untuk kasus penggunaan yang sangat khusus. Dalam kebanyakan kasus lain di mana kesalahan klien telah terjadi karena sintaksis cacat, status 400 Permintaan Buruk harus digunakan.

https://www.keycdn.com/support/422-unprocessable-entity/

Kasing Anda: HTTP 400 adalah kode status yang tepat untuk kasing Anda dari perspektif REST karena secara sintaksis salah untuk mengirim, sales_taxbukan taxJSON yang valid. Ini biasanya ditegakkan oleh sebagian besar kerangka sisi server ketika memetakan JSON ke objek. Namun, ada beberapa implementasi REST yang mengabaikan keyobjek JSON baru . Dalam hal itu, content-typespesifikasi khusus untuk menerima hanya bidang yang valid dapat diberlakukan oleh sisi server.

Skenario Ideal untuk 422:

Dalam dunia yang ideal, 422 lebih disukai dan secara umum dapat diterima untuk mengirim sebagai respons jika server memahami tipe konten entitas permintaan dan sintaks entitas permintaan sudah benar tetapi tidak dapat memproses data karena kesalahan semantiknya.

Situasi 400 lebih dari 422:

Ingat, kode respons 422 adalah kode status HTTP diperpanjang (WebDAV). Masih ada beberapa klien HTTP / perpustakaan front-end yang tidak siap untuk menangani 422. Bagi mereka, ini sesederhana "HTTP 422 salah, karena itu bukan HTTP" . Dari perspektif layanan, 400 tidak terlalu spesifik.

Dalam arsitektur perusahaan, layanan ini sebagian besar digunakan pada lapisan layanan seperti SOA, IDM, dll. Mereka biasanya melayani beberapa klien mulai dari klien asli yang sangat lama hingga klien HTTP terbaru. Jika salah satu klien tidak menangani HTTP 422, opsinya adalah meminta klien untuk meningkatkan atau mengubah kode respons Anda ke HTTP 400 untuk semua orang. Dalam pengalaman saya, ini sangat jarang hari ini tetapi masih ada kemungkinan. Jadi, studi yang cermat tentang arsitektur Anda selalu diperlukan sebelum memutuskan kode respons HTTP.

Untuk menangani situasi seperti ini, lapisan layanan biasanya menggunakan versioningatau mensetup configurationbendera untuk klien kepatuhan HTTP ketat untuk mengirim 400, dan mengirim 422 untuk sisanya. Dengan cara itu mereka memberikan dukungan kompatibilitas mundur untuk konsumen yang sudah ada tetapi pada saat yang sama memberikan kemampuan bagi klien baru untuk mengkonsumsi HTTP 422.

Pembaruan terbaru untuk RFC7321 mengatakan:

The 400 (Bad Request) status code indicates that the server cannot or
   will not process the request due to something that is perceived to be
   a client error (e.g., malformed request syntax, invalid request
   message framing, or deceptive request routing).

Ini mengonfirmasi bahwa server dapat mengirim HTTP 400 untuk permintaan yang tidak valid. 400 tidak merujuk hanya ke kesalahan sintaks lagi , bagaimanapun, 422 masih merupakan respon asli asalkan klien dapat menanganinya.

Pertama, ini adalah pertanyaan yang sangat bagus.

400 Permintaan Buruk - Ketika ada informasi penting yang hilang dari permintaan

mis. Header otorisasi atau header tipe konten. Yang mutlak diperlukan oleh server untuk memahami permintaan. Ini dapat berbeda dari server ke server.

422 Entitas yang tidak dapat diproses - Saat badan permintaan tidak dapat diuraikan.

Ini kurang parah dari 400. Permintaan telah mencapai server. Server telah mengakui permintaan telah mendapatkan struktur dasar yang benar. Tetapi informasi di badan permintaan tidak dapat diuraikan atau dipahami.

mis. Content-Type: application/xmlketika badan permintaan JSON.

Berikut ini adalah artikel yang mencantumkan kode status dan penggunaannya dalam REST APIs. https://metamug.com/article/status-codes-for-rest-api.php

Anda harus benar-benar mengembalikan "200 OK" dan di badan respons sertakan pesan tentang apa yang terjadi dengan data yang diposting. Maka terserah aplikasi Anda untuk memahami pesannya.

Masalahnya, kode status HTTP persis seperti itu - kode status HTTP. Dan itu dimaksudkan hanya memiliki arti pada lapisan transportasi, bukan pada lapisan aplikasi. Lapisan aplikasi harus benar-benar tidak pernah tahu bahwa HTTP sedang digunakan. Jika Anda memindahkan lapisan transportasi Anda dari HTTP ke Homing Pigeons, itu tidak akan mempengaruhi lapisan aplikasi Anda dengan cara apa pun.

Biarkan saya memberi Anda contoh non-virtual. Katakanlah Anda jatuh cinta dengan seorang gadis dan dia mencintai Anda kembali tetapi keluarganya pindah ke negara yang sama sekali berbeda. Dia memberi Anda alamat siputnya yang baru. Secara alami, Anda memutuskan untuk mengiriminya surat cinta. Jadi, Anda menulis surat, memasukkannya ke dalam amplop, menuliskan alamatnya di amplop, menempelkan perangko di atasnya, dan mengirimkannya. Sekarang mari kita pertimbangkan skenario ini

1. Anda lupa menulis nama jalan. Anda akan menerima surat yang belum dibuka kembali dengan pesan tertulis di atasnya yang mengatakan bahwa alamatnya salah. Anda mengacaukan permintaan dan kantor pos penerima tidak dapat menanganinya. Itu sama dengan menerima "400 Permintaan Buruk".
2. Jadi Anda memperbaiki alamatnya dan mengirim surat itu lagi. Tetapi karena beberapa nasib buruk Anda benar-benar salah mengeja nama jalan. Anda akan mendapatkan kembali surat itu dengan pesan yang mengatakan, bahwa alamat itu tidak ada. Itu sama dengan menerima "404 Tidak Ditemukan".
3. Anda memperbaiki alamat lagi dan kali ini Anda berhasil menulis alamat dengan benar. Gadis Anda menerima surat itu dan membalas Anda. Ini sama dengan menerima "200 OK". Namun, ini tidak berarti bahwa Anda akan menyukai apa yang dia tulis dalam suratnya. Ini berarti bahwa dia menerima pesan Anda dan memiliki respons untuk Anda. Sampai Anda membuka amplop dan membaca suratnya, Anda tidak dapat mengetahui apakah dia sangat merindukan Anda atau ingin putus dengan Anda.

Singkatnya: Mengembalikan "200 OK" tidak berarti aplikasi server memiliki kabar baik untuk Anda. Itu hanya berarti ada berita.

PS: Kode status 422 hanya memiliki arti dalam konteks WebDAV. Jika Anda tidak bekerja dengan WebDAV, maka 422 memiliki arti standar yang persis sama dengan kode non-standar lainnya = yang tidak ada.