400 vs 422 respons terhadap POST data

356

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.

David S
sumber
1
kemungkinan duplikat REST: Memetakan kesalahan aplikasi ke kode Status HTTP
Anirudh Ramanathan

Jawaban:

419

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!

Kristian Glass
sumber
5
Jawaban Anda (422) masuk akal bagi saya. Ini juga yang digunakan Rails ( respond_with ) ketika sumber daya tidak dapat diproses karena kesalahan validasi.
Tyler Rick
11
Perhatikan penggunaan 422 dalam spesifikasi non-WebDAV di sini: tools.ietf.org/html/rfc5789#section-2.2
Andrey Shchekin
4
Sama seperti pembaruan, RFC 7231 memiliki deskripsi berbeda untuk kode respons 400 yang mengubah semantik.
Lee Saferite
5
Permintaan maaf saya - saya memperbarui jawaban ini untuk mencerminkan perubahan dalam RFC dan kehilangan kejelasan; Saya akan mencoba refactor. Hampir pasti aman untuk menggunakan 422, tetapi saat ini Anda harus menggunakan 400.
Kristian Glass
2
Saya masih berpikir spek bisa jauh lebih jelas. Contoh-contoh yang diberikan dalam kasus-kasus yang jelas klien melakukan sesuatu yang salah. Situasi OP juga termasuk dalam kategori itu. Namun, ada beberapa kasus seperti "Saya mengerti apa yang Anda minta, tetapi saya menolak untuk melakukannya karena ada beberapa aturan bisnis yang menentangnya" tidak begitu jelas. Ini bukan kesalahan klien, jadi 403 mungkin benar-benar berlaku, per spec yang sama: "Namun, permintaan mungkin dilarang karena alasan yang tidak terkait dengan kredensial". Saya lebih suka memiliki kode terpisah untuk hal-hal terkait izin vs "tidak dapat dilakukan" sekalipun.
Thorarin
38

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

filip26
sumber
4
Kode 422 adalah bagian dari IANA registry iana.org/assignments/http-status-codes/http-status-codes.xhtml sehingga setiap IMHO tidak masuk akal. Bagaimanapun REST API Facebook dan Twitter menciptakan kembali kode mereka sendiri dan tidak menggunakan standar RFC / IANA. Jadi kamu bisa melakukannya.
gavenkoa
15
Bagian 11 secara khusus menyatakan mereka ditambahkan ke seluruh spek dan tidak hanya dalam spek WebDav:The following status codes are added to those defined in HTTP/1.1 [RFC2616].
Steve Tauber
8
Hanya karena kode tersebut dideskripsikan sebagai bagian dari spesifikasi WebDAV, bukan berarti spesifik WebDAV! Kode status seharusnya generik.
perlakukan mod Anda dengan baik
33

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.

Tom Christie
sumber
4
Bukankah 403 Forbidden mungkin juga digunakan untuk konteks ini? Kutipan: Kode status 403 (Terlarang) menunjukkan bahwa server memahami permintaan tersebut tetapi menolak untuk mengesahkannya ... Jika kredensial otentikasi diberikan dalam permintaan, server menganggapnya tidak cukup untuk memberikan akses .... Namun, permintaan mungkin dilarang karena alasan yang tidak terkait dengan kredensial. Jadi sepertinya 403 dapat digunakan untuk menolak permintaan di luar otentikasi.
garbagecollector
1
@garbagecollector perhatikan bahwa "ditolak karena alasan di luar kredensial "! = "ditolak karena alasan di luar otentikasi ." Ada banyak cara untuk mengautentikasi seseorang tanpa menggunakan kredensial, khususnya.
Knetic
@garbagecollector no, kredensial berarti otentikasi ("siapa Anda"), yang akan menjadi 401 saat gagal. Otorisasi ("apa yang bisa Anda lakukan") akan menjadi 403 pada saat kegagalan. Penjelasan lengkap di sini: stackoverflow.com/a/6937030/137948 Tidak berlaku untuk situasi "bidang yang hilang" OP karena kesalahannya akan tetap sama, terlepas dari pengguna mana yang mencobanya. Saya setuju 400 adalah jawaban yang tepat.
Will Sheppard
27

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"
    }
  ]
}
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
sumber
Saya pikir ini adalah jawaban yang benar dan dapat dimengerti.
LEMUEL ADANE
1
Tidak dapat mengunggahnya lebih lanjut. Berharap bahwa lebih banyak jawaban yang dipilih akan merujuk ke yang ini. Spesifikasi (RFC, IANA) gagal untuk memberikan definisi dan perbedaan yang jelas antara keduanya. Jadi jawabannya bermuara pada praktik terbaik dan GitHub memberi kita satu.
Alex Klaus
15

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 .

cdeszaq
sumber
Jawaban yang sangat diremehkan - terima kasih atas penjelasan yang ditulis dengan baik.
puiu
Pikiranku tepat tentang masalah ini! Saya datang dari latar belakang SOAP XML dan konsep skema baru saja masuk ke dalam darah saya dan dokumen JSON bukannya tidak mengumumkan skema mereka. Bagi saya itu adalah apakah server "memahami" permintaan atau tidak. Jika server tidak tahu apa "sales_tax" itu maka itu hanya 400: "Saya tidak tahu apa yang Anda kirim kepada saya tetapi jelas bukan apa yang saya inginkan."
Aleksander Stelmaczonek
4

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/

Clojurevangelist
sumber
1

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.

YuVi
sumber
1

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


sumber
5
422 berarti bahwa sintaksnya valid, tetapi isinya tidak. Mengirim JSON tempat XML diharapkan berarti sintaksnya salah, jadi 400 adalah respons yang benar dalam kasus ini.
Dirk
1
Persis seperti kata Dirk, 422 berarti permintaan yang secara sintaksis valid (dapat diuraikan dan dipahami) tetapi secara semantik tidak valid
Jacek Obarymski
400: ketika permintaan tidak dapat diproses karena sintaks yang tidak valid (mis. Kesalahan parsing); 422: ketika permintaan tidak dapat diproses karena data tidak valid (mis. Kesalahan validasi).
Kitanotori
Contoh Anda untuk 422 tidak valid karena dengan mengirim json dengan jenis media aplikasi / xml, tubuh secara otomatis salah secara sintaksis dan responsnya adalah 400.
manemarron
-15

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.

GoFree
sumber