Situasi dengan penggunaan kode respons HTTP dapat dimasukkan ke dalam bobot dan ukuran: inilah yang terjadi ketika pengembang spesifikasi yang bermaksud baik dihadapkan pada kenyataan yang brutal. Bahkan dengan dua realitas brutal.
Seperti yang telah kita bahas di Bab 10 , salah satu tujuan kesalahan semantik adalah untuk membantu klien memahami apa yang menyebabkan kesalahan. Selama pengembangan spesifikasi HTTP (khususnya, RFC 7231 ), tujuan ini jelas merupakan salah satu tujuan utama. Selain itu, batasan arsitektural REST seperti yang dijelaskan oleh Fjelding dalam tesisnya menunjukkan bahwa tidak hanya klien yang harus memahami semantik kesalahan, tetapi semua agen jaringan (proxy) antara klien dan server dalam arsitektur "berlapis". Dan, menurut ini, nomenklatur kode status HTTP menjelaskan dengan sangat rinci hampir semua masalah yang mungkin terjadi dengan permintaan HTTP: nilai Accept-*
header tidak valid , hilangContent-Length
, metode HTTP tidak didukung, URI terlalu panjang, dan seterusnya.
Tetapi dengan apa yang RFC tidak membantu sama sekali - itu dengan pertanyaan, apa sebenarnya yang harus dilakukan klien atau proxy dengan kesalahan. Seperti yang telah kita bahas, bug dapat dipulihkan atau tidak dapat dipulihkan. Jika kesalahan fatal, maka klien pada umumnya tidak peduli tentang semua peterseli ini dengan kode status dan tajuk, dan terlebih lagi proxy perantara. Untuk ini, sebenarnya, tiga kode sudah cukup:
400
untuk kesalahan terus-menerus (jika Anda hanya mengulangi permintaan, kesalahan tidak akan kemana-mana);404
untuk status ketidakpastian (mencoba kembali permintaan dapat memberikan hasil yang berbeda);500
untuk masalah sisi server ditambah tajukRetry-After
untuk memberi tahu klien kapan harus kembali.
Catatan samping : ngomong-ngomong, perhatikan masalah spesifikasi desain. Secara default, semua 4xx
kode tersebut tidak cache, kecuali: 404
, 405
, 410
, 414
. Kami tidak ragu bahwa ini dilakukan dengan niat baik, tetapi kami menduga bahwa jumlah orang yang mengetahui tentang kehalusan ini kira-kira sama dengan jumlah editor spesifikasi. Akibatnya, kami memiliki banyak situasi (penulis secara pribadi memeriksa konsekuensi salah satunya), ketika 404
-ki dikembalikan secara keliru, tetapi klien menyimpannya dalam cache, sehingga memperpanjang fakup untuk waktu yang tidak terbatas.
โ , - - . , 411 Length Required
. โ . , :
400 Bad Request
, . , , โ ! , , โ REST.
NB: ,
400
, .. URI, , JSON ..,422 Unprocessable Entity
412 Precondition Failed
. , .
403 Forbidden
/ .Forbidden
-, :
- โ ;
- โ ;
- โ ;
- โ ;
- โ - .
403
, (, ) .
409 Conflict
;
.
, / , โ , 400
-, .
: , : โThe response message will usually contain a representation that explains the statusโ. , , , , ( - ?), REST: , ยซยป , .
, : - ยซยป HTTP, . . Web - . , , , , , -. : , - โ .
, . ยฏ\_(ใ)_/ยฏ. โ 401 Unauthorized
: WWW-Authenticate
โ , , , , .. โ Basic
(-, - Web 1.0, ). , , realm
- โ . 401
โ WWW-Authenticate
, , .
: - HTTP , ; ; - , . ( , , โ , , , .) , , 200
-.
?
:
REST RPC. - HTTP . :
200 OK
, โ200
.500 Internal Server Error
.
400 Bad Request
. , API Gateway;
ยซ ยป โ , , , . ; โ - . .
NB: , : RPC- , , - - (,403
429
, - - , HTTP). , , , ยซยป . ;
. , :
- HTTP- , HTTP (..
406 Unacceptable
Accept-Language
, , - ); - , HTTP ( , ; ) โ , -
X-My-API-Error-Reason
; - , . - ( );
- , -, , .
- HTTP- , HTTP (..
, , #3 .
- Teks ini ditulis sebagai bagian dari persiapan bagian mendatang di HTTP API untuk buku saya, pekerjaan sedang dilakukan di GitHub .
Versi bahasa Inggris dari teks yang sama ada di sini .
Saya akan bersyukur jika ada yang meraba-raba di reddit, saya sendiri tidak bisa sesuai dengan aturan reddit.