Misalnya Anda menjalankan permintaan GET untuk users/9
tetapi tidak ada pengguna dengan id # 9. Kode respon terbaik mana?
- 200 OK
- 202 Diterima
- 204 Tidak Ada Konten
- 400 permintaan Buruk
- 404 tidak ditemukan
rest
http
api-design
IMB
sumber
sumber
Jawaban:
TL; DR: Gunakan
404
Lihat Blog Ini . Ini menjelaskan dengan sangat baik.
Ringkasan komentar blog tentang
204
:204 No Content
tidak terlalu berguna sebagai kode respons untuk peramban (meskipun menurut peramban spesifikasi HTTP, Anda perlu memahaminya sebagai kode respons 'jangan ubah tampilan').204 No Content
adalah Namun, sangat berguna untuk layanan web ajax yang mungkin ingin menunjukkan keberhasilan tanpa harus kembali sesuatu. (Terutama dalam kasus sepertiDELETE
atauPOST
yang tidak memerlukan umpan balik).Jawabannya, oleh karena itu, untuk pertanyaan Anda digunakan
404
dalam kasus Anda.204
adalah kode respons khusus yang tidak boleh sering Anda kembali ke browser sebagai tanggapan atas aGET
.Kode respons lain yang bahkan kurang sesuai daripada
204
dan404
:200
harus dikembalikan dengan tubuh apa pun yang berhasil Anda ambil. Tidak tepat ketika entitas yang Anda ambil tidak ada.202
digunakan ketika server sudah mulai bekerja pada suatu objek tetapi objek belum sepenuhnya siap. Tentu tidak demikian di sini. Anda belum memulai, Anda juga tidak akan memulai, konstruksi pengguna 9 dalam menanggapiGET
permintaan. Itu melanggar segala macam aturan.400
digunakan sebagai tanggapan atas permintaan HTTP yang diformat dengan buruk (misalnya header http salah format, segmen yang dipesan salah, dll). Ini hampir pasti akan ditangani oleh kerangka apa pun yang Anda gunakan. Anda tidak harus berurusan dengan ini kecuali Anda menulis server sendiri dari awal. Sunting : RFC yang lebih baru sekarang memungkinkan 400 digunakan untuk permintaan yang secara semantik tidak valid.Deskripsi Wikipedia tentang kode status HTTP sangat membantu. Anda juga dapat melihat definisi dalam dokumen HTTP / 1.1 RFC2616 di www.w3.org
sumber
204
kode respons (Tidak Ada Konten)./badurl
atau/user/9
ketika pengguna seperti itu tidak ada. Pengembang dapat membantu dengan menambahkan frasa alasan yang lebih baik daripada 'Tidak Ditemukan', tetapi tidak diharuskan.The server has not found anything matching the Request-URI
. Server web / aplikasi sebenarnya telah menemukan AKSI yang cocok dengan Request-URI, meskipun server db belum. Namun, itu juga mengatakanThis status code is commonly used when [...] no other response is applicable
, jadi saya pikir itu memvalidasi penggunaannya agak (bahkan jika saya tidak setuju dengan / menyukainya).Saya sangat menentang 404 yang mendukung 204 atau 200 dengan data kosong. Atau setidaknya satu harus menggunakan entitas respons dengan 404.
Permintaan diterima dan diproses dengan benar - itu memang memicu kode aplikasi di server, sehingga orang tidak bisa benar-benar mengatakan bahwa itu adalah kesalahan klien dan dengan demikian seluruh kelas kode kesalahan klien (4xx) tidak pas.
Lebih penting lagi, 404 dapat terjadi karena sejumlah alasan teknis. Misalnya aplikasi yang sementara dinonaktifkan atau dihapus pada server, masalah koneksi proxy dan yang lainnya. Oleh karena itu klien tidak dapat membedakan antara 404 yang berarti "set hasil kosong" dan 404 yang berarti "layanan tidak dapat ditemukan, coba lagi nanti".
Ini bisa berakibat fatal: Bayangkan layanan akuntansi di perusahaan Anda yang mencantumkan semua karyawan yang mendapat bonus tahunan. Sayangnya, suatu saat ketika disebut mengembalikan 404. Apakah itu berarti bahwa tidak ada yang jatuh tempo untuk bonus, atau bahwa aplikasi saat ini sedang down untuk penyebaran baru?
-> Untuk aplikasi yang peduli dengan kualitas data mereka, 404 tanpa entitas respon oleh karena itu cukup banyak yang tidak bisa digunakan.
Juga, banyak kerangka kerja klien merespons 404 dengan melemparkan pengecualian tanpa ada pertanyaan lebih lanjut. Ini memaksa pengembang klien untuk menangkap pengecualian itu, untuk mengevaluasinya, dan kemudian memutuskan berdasarkan apakah akan mencatatnya sebagai kesalahan yang diambil oleh misalnya komponen pemantauan atau apakah akan mengabaikannya. Bagi saya itu juga tampaknya tidak cantik.
Keuntungan 404 lebih dari 204 adalah dapat mengembalikan entitas respons yang mungkin berisi beberapa informasi tentang mengapa sumber daya yang diminta tidak ditemukan. Tetapi jika itu benar-benar relevan, maka orang juga dapat mempertimbangkan untuk menggunakan respons 200 OK dan merancang sistem dengan cara yang memungkinkan respons kesalahan dalam data payload. Atau, seseorang dapat menggunakan payload dari respons 404 untuk mengembalikan informasi terstruktur kepada pemanggil. Jika ia menerima misalnya halaman html alih-alih XML atau JSON yang dapat diuraikan, maka itu merupakan indikator yang baik bahwa ada kesalahan teknis alih-alih jawaban "tidak ada hasil" yang mungkin valid dari sudut pandang pemanggil. Atau orang dapat menggunakan header respons HTTP untuk itu.
Namun saya lebih suka 204 atau 200 dengan respon kosong. Dengan cara itu status pelaksanaan teknis permintaan dipisahkan dari hasil logis permintaan. 2xx berarti "eksekusi teknis ok, ini hasilnya, tangani".
Saya pikir dalam banyak kasus itu harus diserahkan kepada klien untuk memutuskan apakah hasil kosong dapat diterima atau tidak. Dengan mengembalikan 404 tanpa entitas respons meskipun eksekusi teknis yang benar, klien dapat memutuskan untuk menganggap kasus sebagai kesalahan yang tidak ada kesalahan.
Analogi cepat lain: Mengembalikan 404 untuk "tidak ada hasil yang ditemukan" adalah seperti melempar DatabaseConnectionException jika kueri SQL tidak mengembalikan hasil. Itu bisa menyelesaikan pekerjaan, tetapi ada banyak kemungkinan penyebab teknis yang melemparkan pengecualian yang sama yang kemudian akan keliru untuk hasil yang valid.
sumber
503 Service Unavailable
./users
rute, tetapi/users/9
, yaitu "Pengguna yang dikenal sebagai # 9"), sehingga perbandingan 'set hasil kosong' Anda tidak masuk akal. 404 berarti bahwa objek itu tidak ada.Pada awalnya, saya pikir 204 akan masuk akal, tetapi setelah diskusi, saya percaya 404 adalah satu-satunya jawaban yang benar. Pertimbangkan data berikut:
Pengguna: John, Peter
Beberapa latar belakang:
pencarian mengembalikan array, hanya saja tidak ada kecocokan tetapi memiliki konten: array kosong .
404 tentu saja terkenal dengan url yang tidak didukung oleh server yang diminta, tetapi sumber daya yang hilang sebenarnya sama.
Meskipun
/users/:name
dicocokkan denganusers/kyle
, pengguna Kyle tidak tersedia sumber daya sehingga 404 masih berlaku. Ini bukan permintaan pencarian, ini adalah referensi langsung oleh url dinamis , jadi 404 itu.Pokoknya, dua sen saya :)
sumber
Jika diharapkan sumber daya ada, tetapi mungkin kosong, saya berpendapat bahwa mungkin lebih mudah untuk mendapatkan 200 OK dengan representasi yang menunjukkan bahwa hal itu kosong.
Jadi saya lebih suka / hal mengembalikan 200 OK dengan {"Item": []} daripada 204 tanpa apa-apa, karena dengan cara ini koleksi dengan 0 item dapat diperlakukan sama seperti koleksi dengan satu atau lebih banyak item di dalamnya.
Saya baru saja meninggalkan 204 No Content untuk PUTs dan DELETEs, di mana mungkin memang benar ada representasi yang bermanfaat.
Jika / hal / 9 benar-benar tidak ada, 404 sesuai.
sumber
customers/1/addressbook
, cara RPC adalah memanggil titik akhir sepertiGetCustomerAddressBook
dan menerima data atau pada dasarnya nol dan tidak perlu terlalu khawatir tentang kompleksitas HTTP. Ada pro dan kontra untuk keduanya.Dalam proyek sebelumnya, saya telah menggunakan 404. Jika tidak ada pengguna 9, maka objek tidak ditemukan. Oleh karena itu 404 Tidak Ditemukan sesuai.
Untuk objek ada, tetapi tidak ada data, 204 Tidak Ada Konten akan sesuai. Saya pikir dalam kasus Anda, objeknya tidak ada sekalipun.
sumber
Menurut posting w3 ,
Permintaan telah berhasil. Informasi yang dikembalikan bersama respons bergantung pada metode yang digunakan dalam permintaan
Permintaan telah diterima untuk diproses, tetapi pemrosesan belum selesai.
Server telah memenuhi permintaan tetapi tidak perlu mengembalikan entitas-badan, dan mungkin ingin mengembalikan metainformation yang diperbarui.
Permintaan tidak dapat dipahami oleh server karena sintaksis yang salah. Klien TIDAK HARUS mengulangi permintaan tanpa modifikasi
Permintaan membutuhkan otentikasi pengguna. Responsnya HARUS menyertakan bidang tajuk WWW-Otentikasi
Server belum menemukan sesuatu yang cocok dengan Permintaan-URI. Tidak ada indikasi yang diberikan apakah kondisinya sementara atau permanen
sumber
204 No Content
ketika tidak menemukan hasil. Tidak404
, ini memiliki hasil untuk Anda, tetapi tidak memiliki konten ..Untuk meringkas atau menyederhanakan,
2xx: Data opsional: URI yang terbentuk dengan baik: Kriteria bukan bagian dari URI: Jika kriteria tersebut opsional, dapat ditentukan dalam @RequestBody dan @RequestParam harus mengarah ke 2xx. Contoh: filter berdasarkan nama / status
4xx: Data yang diharapkan: URI yang tidak terbentuk dengan baik: Kriteria adalah bagian dari URI: Jika kriteria itu wajib yang hanya dapat ditentukan dalam @PathVariable, maka harus mengarah ke 4xx. Contoh: pencarian dengan id unik.
Jadi untuk situasi yang ditanyakan: "users / 9" akan menjadi 4xx (mungkin 404) Tetapi untuk "users? Name = superman" harus 2xx (mungkin 204)
sumber
Ada dua pertanyaan yang diajukan. Satu di judul dan satu di contoh. Saya pikir ini sebagian mengarah pada jumlah perselisihan tentang respon mana yang sesuai.
Judul pertanyaan menanyakan tentang data kosong. Data kosong masih berupa data tetapi tidak sama dengan tidak ada data. Jadi ini menyarankan meminta set hasil, yaitu daftar, mungkin dari
/users
. Jika daftar kosong itu masih daftar karena itu 204 (Tidak Ada Konten) yang paling tepat. Anda baru saja meminta daftar pengguna dan telah disediakan satu, kebetulan tidak memiliki konten.Contoh yang diberikan bukannya bertanya tentang objek tertentu, pengguna
/users/9
,. Jika pengguna # 9 tidak ditemukan maka tidak ada objek pengguna yang dikembalikan. Anda meminta sumber daya tertentu (objek pengguna) dan tidak diberikan karena tidak ditemukan, jadi 404 sesuai.Saya pikir cara untuk menyelesaikannya adalah jika Anda dapat menggunakan respons seperti yang Anda harapkan tanpa menambahkan pernyataan kondisional, kemudian gunakan 204 jika tidak gunakan 404.
Dalam contoh saya, saya dapat mengulangi daftar kosong tanpa memeriksa untuk melihat apakah ada konten, tapi saya tidak bisa menampilkan data objek pengguna pada objek nol tanpa merusak sesuatu atau menambahkan tanda centang untuk melihat apakah itu nol.
Anda tentu saja dapat mengembalikan objek menggunakan pola objek nol jika itu sesuai dengan kebutuhan Anda, tetapi itu adalah diskusi untuk utas lainnya.
sumber
Setelah melihat pertanyaan, Anda tidak boleh menggunakan
404
mengapa?Berdasarkan RFC 7231 kode status yang benar adalah
204
Dalam jawaban di atas saya perhatikan 1 kesalahpahaman kecil:
1.- sumber daya adalah:
/users
2.-
/users/8
bukan sumber daya, ini adalah: sumber daya/users
dengan parameter rute8
, konsumen mungkin tidak dapat melihatnya dan tidak mengetahui perbedaannya, tetapi penerbit mengetahui dan harus mengetahui hal ini! ... jadi ia harus mengembalikan respons yang akurat bagi konsumen. Titik.begitu:
Berdasarkan RFC: 404 tidak benar karena sumber dayanya
/users
ditemukan, tetapi logika yang dieksekusi menggunakan parameter8
tidak menemukan apa puncontent
untuk kembali sebagai respons, jadi jawaban yang benar adalah:204
Poin utama di sini adalah:
404
bahkan sumber daya tidak ditemukan untuk memproses logika internal204
is a: Saya menemukan sumber daya, logikanya dieksekusi tetapi saya tidak menemukan data menggunakan kriteria Anda yang diberikan dalam parameter rute jadi saya tidak bisa mengembalikan apa pun kepada Anda. Maaf, verifikasi kriteria Anda dan hubungi saya lagi.200
: ok saya menemukan sumber daya, logika dieksekusi (bahkan ketika saya tidak dipaksa untuk mengembalikan apa pun) mengambil ini dan menggunakannya sesuka Anda.205
: (opsi terbaik dari respons GET) Saya menemukan sumber daya, logika dijalankan, saya memiliki beberapa konten untuk Anda, gunakan dengan baik, oh omong-omong jika Anda akan membagikan ini dalam tampilan, segarkan tampilan ke tampilkan itu.Semoga ini bisa membantu.
sumber
Apa jawaban yang ada tidak dijabarkan adalah membuat perbedaan apakah Anda menggunakan parameter jalur atau parameter kueri.
/users/9
, responsnya harus404
karena sumber daya itu tidak ditemukan./users/9
adalah sumber daya, dan hasilnya adalah unary, atau kesalahan, itu tidak ada. Ini bukan monad./users?id=9
, responsnya harus204
karena sumber daya/users
ditemukan tetapi tidak dapat mengembalikan data apa pun. Sumber daya/users
ada dan hasilnya adalah n-ary, itu ada bahkan jika itu kosong. Jikaid
unik, ini adalah monad.Apakah akan menggunakan parameter jalur atau parameter kueri tergantung pada use case. Saya lebih suka parameter jalur untuk argumen wajib, normatif, atau identifikasi dan parameter kueri untuk argumen opsional, non-normatif, atau atribut yang dikaitkan (seperti paging, lokal collation, dan sebagainya). Dalam REST API, saya akan menggunakan
/users/9
tidak/users?id=9
terutama karena bersarang mungkin untuk mendapatkan "catatan anak" seperti/users/9/ssh-keys/0
untuk mendapatkan kunci publik ssh pertama atau/users/9/address/2
untuk mendapatkan alamat pos ketiga.Saya lebih suka menggunakan 404. Inilah alasannya:
204
seperti sebuahvoid
metode. Saya tidak akan menggunakannya untukGET
, hanya untukPOST
,PUT
, danDELETE
. Saya membuat pengecualian jikaGET
pengidentifikasi adalah parameter kueri bukan parameter jalur.NoSuchElementException
,ArrayIndexOutOfBoundsException
atau sesuatu seperti itu, disebabkan oleh klien menggunakan id yang tidak ada, jadi, itu adalah kesalahan klien.204
berarti cabang tambahan dalam kode yang dapat dihindari. Ini memperumit kode klien, dan dalam beberapa kasus juga memperumit kode server (tergantung pada apakah Anda menggunakan entitas / model monads atau entitas / model biasa; dan saya sangat menyarankan untuk menjauh dari entitas / model monads, itu dapat menyebabkan bug yang buruk di mana karena dari monad yang Anda pikir operasi berhasil dan mengembalikan 200 atau 204 ketika Anda seharusnya mengembalikan sesuatu yang lain).Terakhir tetapi tidak kalah pentingnya: Konsistensi
GET /users/9
PUT /users/9
danDELETE /users/9
PUT /users/9
danDELETE /users/9
harus kembali204
jika pembaruan atau penghapusan berhasil. Jadi apa yang harus mereka kembalikan jika pengguna 9 tidak ada? Tidak masuk akal memiliki situasi yang sama disajikan sebagai kode status yang berbeda tergantung pada metode HTTP yang digunakan.Selain itu, bukan normatif, tetapi alasan budaya: Jika
204
digunakan untukGET /users/9
hal berikutnya yang akan terjadi dalam proyek adalah bahwa seseorang berpikir kembali204
itu baik untuk metode n-ary. Dan itu menyulitkan kode klien, karena alih-alih hanya memeriksa2xx
dan kemudian mendekodekan tubuh, klien sekarang harus secara khusus memeriksa204
dan dalam hal itu lewati mendekode tubuh. Bud apa yang dilakukan klien sebagai gantinya? Buat array kosong? Kalau begitu, mengapa tidak menggunakannya? Jika klien membuat array kosong, 204 adalah bentuk kompresi bodoh. Jika klien menggunakannull
sebagai gantinya, kaleng cacing yang sama sekali berbeda dibuka.sumber
Twitter menggunakan 404 dengan pesan kesalahan khusus seperti "Tidak ada data ditemukan".
Ref: https://developer.twitter.com/en/docs/basics/response-codes.html
sumber
204 lebih tepat. Terutama ketika Anda memiliki sistem peringatan untuk memastikan situs web Anda aman, 404 dalam kasus ini akan menyebabkan kebingungan karena Anda tidak tahu bahwa 404 peringatan adalah kesalahan backend atau permintaan normal tetapi respons kosong.
sumber
Saya akan mengatakan, tidak ada yang benar-benar tepat. Seperti yang telah dikatakan - misalnya oleh @anneb, saya juga berpikir bahwa bagian dari masalah muncul dari penggunaan kode respons HTTP untuk mengangkut status yang berkaitan dengan layanan RESTful. Apa pun yang dikatakan layanan REST tentang pemrosesannya sendiri harus diangkut melalui kode khusus REST.
1
Saya berpendapat bahwa, jika server HTTP menemukan layanan apa pun yang siap untuk menjawab permintaan yang dikirim, ia seharusnya tidak merespons dengan HTTP 404 - pada akhirnya, sesuatu ditemukan oleh server - kecuali jika diberitahukan secara eksplisit oleh layanan yang memproses permintaan.
Mari kita asumsikan sejenak URL berikut:
http://example.com/service/return/test
.404
sudah benar. Hal yang sama berlaku, jika ia meminta beberapa jenis layanan untuk memberikan file ini dengan tepat dan layanan itu memberi tahu bahwa tidak ada nama itu yang ada.Tanpa respons dari layanan secara eksplisit yang memerlukan perilaku berbeda, server HTTP hanya dapat mengatakan 3 hal:
503
jika layanan yang seharusnya menangani permintaan tidak berjalan atau merespons;200
jika tidak, server HTTP dapat benar-benar memenuhi permintaan - tidak peduli apa layanan akan katakan nanti;400
atau404
untuk menunjukkan bahwa tidak ada layanan seperti itu (yang bertentangan dengan "ada tetapi offline") dan tidak ada lagi yang ditemukan.2
Untuk kembali ke pertanyaan yang ada: Saya pikir pendekatan terbersih adalah dengan tidak menggunakan HTTP kode respons apa pun selain yang dikatakan sebelumnya. Jika layanan hadir dan merespons, kode HTTP harus 200. Respons harus berisi status layanan yang dikembalikan dalam tajuk terpisah - di sini, layanan dapat mengatakan
REST:EMPTY
misal jika diminta untuk mencari sth. dan penelitian itu kembali kosong;REST:NOT FOUND
jika diminta khusus untuk sth. "Seperti ID" - baik nama file atau sumber daya dengan ID atau entri No. 24, dll. - dan sumber daya spesifik itu tidak ditemukan (biasanya, satu sumber daya khusus diminta dan tidak ditemukan);REST:INVALID
jika ada bagian dari permintaan yang dikirim tidak dikenali oleh layanan.(perhatikan bahwa saya mengawali ini dengan "REST:" dengan sengaja untuk menandai fakta bahwa sementara ini mungkin memiliki nilai yang sama atau kata-kata seperti halnya kode respons HTTP, mereka sangat berbeda.)
3
Mari kita kembali ke URL di atas dan memeriksa case B di mana layanan menunjukkan ke server HTTP bahwa itu tidak menangani permintaan ini sendiri tetapi meneruskannya ke
SERVICE
. HTTP hanya melayani apa yang dikembalikanSERVICE
, tidak tahu apa-apa tentangreturn/test
bagian yang ditanganiSERVICE
. Jika layanan itu berjalan, HTTP harus kembali200
karena memang menemukan sesuatu untuk menangani permintaan.Status dikembalikan oleh
SERVICE
(dan yang, seperti yang disebutkan di atas, ingin dilihat di header terpisah) tergantung pada tindakan apa yang sebenarnya diharapkan:return/test
meminta sumber daya tertentu: jika ada, kembalikan dengan statusREST:FOUND
; jika sumber daya itu tidak ada, kembalilahREST:NOT FOUND
; ini dapat diperpanjang untuk kembaliREST:GONE
jika kita tahu itu pernah ada dan tidak akan kembali, danREST:MOVED
jika kita tahu itu sudah hollywoodreturn/test
dianggap operasi pencarian atau seperti filter: jika set hasil kosong, kembalikan set kosong dalam jenis yang diminta dan statusREST:EMPTY
; satu set hasil dalam jenis yang diminta dan statusREST:SUCCESS
return/test
bukan operasi yang dikenali olehSERVICE
: kembaliREST:ERROR
jika benar-benar salah (misalnya kesalahan ketikretrun/test
), atauREST:NOT IMPLEMENTED
dalam kasus itu direncanakan untuk nanti.4
Perbedaan ini jauh lebih bersih daripada mencampur dua hal yang berbeda. Ini juga akan membuat proses debug lebih mudah dan pemrosesan hanya sedikit lebih kompleks, jika sama sekali.
Ringkasan
Masalah dan diskusi muncul dari fakta bahwa kode respons HTTP digunakan untuk menunjukkan status layanan yang hasilnya dilayani oleh HTTP, atau untuk menunjukkan sth. itu tidak dalam lingkup server HTTP itu sendiri. Karena perbedaan ini, pertanyaan tidak dapat dijawab dan semua pendapat tunduk pada banyak diskusi.
Keadaan permintaan diproses oleh layanan dan bukan server HTTP BENAR-BENAR TIDAK BISA (RFC 6919) diberikan oleh kode respons HTTP. Kode HTTP HARUS (RFC 2119) hanya berisi informasi yang dapat diberikan oleh server HTTP dari cakupannya sendiri: yaitu, apakah layanan ditemukan untuk memproses permintaan atau tidak.
Sebagai gantinya, cara yang berbeda HARUS digunakan untuk memberi tahu konsumen tentang keadaan permintaan ke layanan yang sebenarnya memproses permintaan tersebut. Proposal saya adalah melakukannya melalui tajuk tertentu. Idealnya, nama header dan isinya mengikuti standar yang memudahkan konsumen untuk bekerja dengan tanggapan tesis.
sumber
Menurut RFC7231 - halaman59 ( https://tools.ietf.org/html/rfc7231#page-59 ) definisi dari 404 kode respon adalah:
6.5.4. 404 Tidak Ditemukan Kode status 404 (Tidak Ditemukan) menunjukkan bahwa server asal tidak menemukan representasi saat ini untuk sumber daya target atau tidak mau mengungkapkan bahwa ada. Kode status 404 tidak menunjukkan apakah kekurangan representasi ini bersifat sementara atau permanen; kode status 410 (Hilang) lebih disukai daripada 404 jika server asal tahu, mungkin melalui beberapa cara yang dapat dikonfigurasi, bahwa kondisi tersebut cenderung permanen. Respons 404 dapat disimpan dalam cache secara default; yaitu, kecuali dinyatakan sebaliknya oleh definisi metode atau kontrol cache eksplisit (lihat Bagian 4.2.2 dari [RFC7234]).
Dan hal utama yang menimbulkan keraguan adalah definisi sumber daya dalam konteks di atas. Menurut RFC yang sama (7231) definisi sumber daya adalah:
Sumber: Target permintaan HTTP disebut "sumber". HTTP tidak membatasi sifat sumber daya; itu hanya mendefinisikan antarmuka yang dapat digunakan untuk berinteraksi dengan sumber daya. Setiap sumber diidentifikasi oleh Uniform Resource Identifier (URI), seperti yang dijelaskan dalam Bagian 2.7 dari [RFC7230]. Ketika klien membuat pesan permintaan HTTP / 1.1, ia mengirimkan target URI dalam salah satu dari berbagai bentuk, sebagaimana didefinisikan dalam (Bagian 5.3 dari [RFC7230]). Ketika permintaan diterima, server merekonstruksi URI permintaan yang efektif untuk sumber daya target (Bagian 5.5 dari [RFC7230]). Salah satu tujuan desain HTTP adalah untuk memisahkan identifikasi sumber daya dari semantik permintaan, yang dimungkinkan dengan memasukkan semantik permintaan dalam metode permintaan (Bagian 4) dan beberapa bidang tajuk pengubah permintaan (Bagian 5).
Jadi dalam pemahaman saya kode status 404 tidak boleh digunakan pada permintaan GET yang berhasil dengan hasil kosong. (Contoh: daftar tanpa hasil untuk filter tertentu)
sumber
Hal-hal seperti itu bisa subjektif dan ada beberapa argumen yang menarik dan beragam di kedua sisi. Namun [menurut saya] mengembalikan 404 untuk data yang hilang tidak benar . Berikut ini deskripsi yang disederhanakan untuk memperjelas ini:
Tidak ada yang rusak, titik akhir ditemukan, dan tabel dan kolom ditemukan sehingga DB ditanya dan data "berhasil" dikembalikan!
Sekarang - apakah "respons berhasil" itu memiliki data atau tidak, Anda meminta respons terhadap data "potensial" dan respons dengan data "potensial" terpenuhi. Tidak ada, kosong dll adalah data yang valid.
200 berarti permintaan apa pun yang kami lakukan berhasil. Saya meminta data, tidak ada yang salah dengan HTTP / REST, dan karena data (meskipun kosong) dikembalikan, "permintaan data" saya berhasil.
Kembalikan 200 dan biarkan pemohon berurusan dengan data kosong karena setiap skenario tertentu menjaminnya!
Pertimbangkan contoh ini:
Data ini menjadi kosong sepenuhnya valid. Ini berarti bahwa pengguna tidak memiliki pelanggaran. Ini adalah 200 karena semuanya valid, seperti yang dapat saya lakukan:
Jika Anda menganggap ini sebagai 404, apa yang Anda katakan? Pelanggaran pengguna tidak dapat ditemukan? Sekarang, secara tata bahasa itu benar, tapi itu tidak benar di dunia REST jika keberhasilan atau kegagalan adalah tentang permintaan. Data "pelanggaran" untuk pengguna ini dapat ditemukan dengan sukses, ada nol pelanggaran - bilangan real yang mewakili keadaan yang valid.
[Catatan nakal ..]
Dalam judul Anda, secara tidak sadar Anda setuju bahwa 200 adalah respons yang benar:
Berikut adalah beberapa hal yang perlu dipertimbangkan ketika memilih kode status mana yang akan digunakan, terlepas dari subjektivitas dan pilihan rumit:
sumber
Menyandikan konten respons dengan enum umum yang memungkinkan klien untuk mengaktifkannya dan garpu logika sesuai. Saya tidak yakin bagaimana klien Anda akan membedakan perbedaan antara "data tidak ditemukan" 404 dan "sumber daya web tidak ditemukan" 404? Anda tidak ingin seseorang menjelajah ke pengguna Z / 9 dan meminta klien bertanya-tanya seolah-olah permintaan itu valid tetapi tidak ada data yang dikembalikan.
sumber
Mengapa tidak menggunakan 410? Ini menunjukkan sumber daya yang diminta tidak ada lagi dan klien diharapkan tidak pernah membuat permintaan untuk sumber daya itu, dalam kasus Anda
users/9
.Anda dapat menemukan rincian lebih lanjut tentang 410 di sini: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
sumber
Sangat menyedihkan bahwa sesuatu yang begitu sederhana dan didefinisikan dengan baik menjadi "berbasis opini" di utas ini.
Server HTTP hanya mengetahui "entitas", yang merupakan abstraksi untuk konten apa pun, baik itu halaman web statis, daftar hasil pencarian, daftar entitas lain, deskripsi json tentang sesuatu, file media, dll.
Setiap entitas tersebut diharapkan dapat diidentifikasi oleh URL yang unik, misalnya
Jika server menemukan sumber daya dengan URL yang diberikan, tidak peduli apa isinya - 2G data, null, {}, [] - selama ada, itu akan menjadi 200. Tetapi jika entitas tersebut adalah tidak dikenal ke server, DIHARAPKAN untuk mengembalikan 404 "Tidak Ditemukan".
Satu kebingungan tampaknya berasal dari pengembang yang berpikir jika aplikasi memiliki penangan untuk bentuk jalur tertentu, seharusnya tidak menjadi kesalahan. Di mata protokol HTTP, tidak masalah apa yang terjadi di internal server (mis. Apakah router default merespons atau handler untuk bentuk lintasan tertentu), selama tidak ada entitas yang cocok pada server ke server. URL yang diminta (yang meminta file MP3, halaman web, objek pengguna dll), yang akan mengembalikan konten yang valid (kosong atau sebaliknya), itu harus 404 (atau 410 dll).
Titik kebingungan lainnya tampaknya berada di sekitar "tidak ada data" dan "tidak ada entitas". Yang pertama adalah tentang konten suatu entitas, dan yang terakhir tentang keberadaannya.
Contoh 1:
Contoh 2:
Contoh 3:
sumber
404 akan sangat membingungkan bagi klien mana pun jika Anda kembali hanya karena tidak ada data sebagai respons.
Bagi saya, Kode Respon 200 dengan tubuh kosong sudah cukup untuk memahami bahwa semuanya sempurna tetapi tidak ada data yang cocok dengan persyaratan.
sumber
Menurut Microsoft: Controller mengembalikan tipe di ASP.NET Core web API , gulir ke bawah hampir ke bawah, Anda menemukan uraian berikut tentang 404 yang berkaitan dengan objek yang tidak ditemukan dalam database. Di sini mereka menyarankan bahwa 404 sesuai untuk Data Kosong.
sumber
Seperti yang dinyatakan oleh banyak orang, 404 menyesatkan dan tidak memungkinkan klien untuk melakukan diskriminasi jika permintaan uri tidak ada, atau jika uri yang diminta tidak dapat mengambil sumber daya yang diminta.
Status 200 diharapkan berisi data sumber daya - jadi itu bukan pilihan yang tepat. Status 204 berarti sesuatu yang lain sepenuhnya dan tidak boleh digunakan sebagai respons untuk permintaan GET.
Semua status lain yang ada tidak berlaku, karena satu dan lain hal.
Saya telah melihat topik ini dibahas berulang-ulang di banyak tempat. Bagi saya, sangat jelas bahwa untuk menghilangkan kebingungan seputar topik, diperlukan status kesuksesan yang berdedikasi. Sesuatu seperti " 209 - Tidak ada sumber daya untuk ditampilkan".
Ini akan menjadi status 2xx karena tidak menemukan ID tidak boleh dianggap sebagai kesalahan klien (jika klien tahu semua yang ada di DB server, mereka tidak perlu meminta apa pun ke server, bukan?). Status khusus ini akan mengatasi semua masalah yang diperdebatkan dengan menggunakan status lain.
Satu-satunya pertanyaan adalah: bagaimana saya membuat RFC menerima ini sebagai standar?
sumber