Kapan menggunakan kode status HTTP 404 dalam API


58

Saya mengerjakan sebuah proyek dan setelah berdebat dengan orang-orang di tempat kerja selama lebih dari satu jam. Saya memutuskan untuk tahu apa yang dikatakan orang-orang di stack-exchange.

Kami sedang menulis API untuk suatu sistem, ada permintaan yang harus mengembalikan pohon Organisasi atau pohon Sasaran.

Pohon Organisasi adalah organisasi tempat pengguna berada, dengan kata lain, pohon ini harus selalu ada. Dalam organisasi, pohon tujuan harus selalu ada. (Di situlah argumen dimulai). Dalam kasus di mana pohon itu tidak ada, rekan kerja saya memutuskan bahwa akan benar untuk menjawab jawaban dengan kode status 200. Dan kemudian mulai meminta saya untuk memperbaiki kode saya karena aplikasi itu berantakan ketika tidak ada pohon.

Saya akan mencoba untuk menyimpan api dan amarah.

Saya menyarankan untuk meningkatkan kesalahan 404 ketika tidak ada pohon. Paling tidak saya akan tahu bahwa ada sesuatu yang salah. Saat menggunakan 200, saya harus menambahkan cek khusus untuk respons saya dalam panggilan balik sukses untuk menangani kesalahan. Saya berharap untuk menerima objek, tetapi saya mungkin benar-benar menerima respons kosong karena tidak ada yang ditemukan. Kedengarannya benar-benar adil untuk menandai respons sebagai 404. Dan kemudian perang dimulai dan saya mendapat pesan bahwa saya tidak mengerti skema kode status HTTP. Jadi saya di sini dan bertanya ada apa dengan 404 dalam kasus ini? Saya bahkan mendapat argumen "Tidak menemukan apa pun, jadi benar untuk mengembalikan 200". Saya percaya itu salah karena pohon itu harus selalu ada. Jika kami tidak menemukan apa pun dan kami mengharapkan sesuatu, itu seharusnya 404.

Info lebih lanjut,

Saya lupa menambahkan url yang diambil.

Organisasi

/OrgTree/Get

Tujuan

/GoalTree/GetByDate?versionDate=...
/GoalTree/GetById?versionId=...

Kesalahan saya, kedua parameter diperlukan. Jika ada versiDate yang dapat diuraikan ke tanggal disediakan, itu akan mengembalikan revisi penutup. Jika Anda memasukkan sesuatu di masa lalu, itu akan mengembalikan revisi pertama. Jika oleh Id dengan id yang tidak ada, saya menduga itu akan mengembalikan respons kosong dengan 200.

Tambahan

Juga, saya percaya jawaban terbaik untuk masalah ini adalah untuk membuat objek default ketika organisasi dibuat, tidak memiliki pohon seharusnya tidak menjadi kasus yang valid dan harus dilihat sebagai perilaku yang tidak terdefinisi. Tidak mungkin akun dapat digunakan tanpa kedua pohon. Untuk alasan itu, mereka harus selalu ada.

juga saya ditautkan ini (yang serupa tetapi saya tidak dapat menemukannya)

http://viswaug.files.wordpress.com/2008/11/http-headers-status1.png


Tolong jelaskan: bagaimana aplikasi bisa berantakan ketika tidak ada pohon, jika selalu ada pohon dengan prasyarat ? (Saya setuju dengan Anda sepertinya 404)
Andres F.

Yah kodenya tidak memeriksa null, dan mengurai string json dan sebagai objek. Di beberapa tempat dalam kode, objek yang "dimuat" tidak ada karena tidak dapat ditemukan secara internal.
Loïc Faure-Lacroix

4
Akan lebih jelas jika Anda memberikan URI untuk sumber daya yang Anda coba akses. Jika itu / tujuan / Anda mengembalikan 200 dan set kosong. Jika Anda mencoba mengakses / tujuan / {goal_id} maka Anda mengembalikan 404. Jika Anda mengembalikan 404 untuk permintaan / tujuan /, itu berarti bahwa URI tidak ada dan tidak boleh digunakan lagi.
imel96

1
Masih dalam kedua kasus, pertanyaan itu tetap ada. Apa yang harus /GoalTree/GetById?versionId=CompletelyInvalidIDdikembalikan? Tidak berhasil, karena sumber daya yang disebutkan /GoalTree/GetById?versionId=CompletelyInvalidIDsecara harfiah tidak ditemukan.

2
Hebat, sekarang diskusi telah bergeser dari pekerjaan Anda ke internet! Itu tak terbendung sekarang!
Carlos Campderrós

Jawaban:


80

Jika ragu, lihat dokumentasi . Meninjau definisi W3C untuk kode Status HTTP, memberi kami ini:

200 OK - Permintaan telah berhasil. Informasi yang dikembalikan bersama respons bergantung pada metode yang digunakan dalam permintaan.

404 Tidak Ditemukan - Server belum menemukan sesuatu yang cocok dengan Request-URI.

Dalam konteks API Anda, itu sangat tergantung pada bagaimana kueri dibuat dan bagaimana objek diambil. Tapi, interpretasi saya selalu seperti itu:

  • Jika saya meminta objek tertentu, dan itu ada 200kode kembali , jika tidak ada mengembalikan 404kode yang benar .
  • Tapi, jika saya meminta satu set objek yang cocok dengan kueri, set nol adalah respons yang valid dan saya ingin yang dikembalikan dengan 200kode. Alasan untuk ini adalah bahwa kueri itu valid, berhasil, dan kueri tidak mengembalikan apa pun.

Jadi dalam hal ini Anda benar , layanan tidak mencari "hal tertentu" itu meminta hal tertentu, jika hal itu tidak ditemukan katakan dengan jelas.

Saya pikir Wikipedia lebih baik:

200 OK - ... Respons aktual akan bergantung pada metode permintaan yang digunakan. Dalam permintaan GET, respons akan berisi entitas yang sesuai dengan sumber daya yang diminta.

404 Tidak Ditemukan - Sumber daya yang diminta tidak dapat ditemukan tetapi mungkin tersedia lagi di masa depan. Permintaan selanjutnya oleh klien diizinkan.

Tampak jelas bagi saya.

Mengenai contoh permintaan

/GoalTree/GetByDate?versionDate=...
/GoalTree/GetById?versionId=...

Untuk format, Anda berkata, Anda selalu mengembalikan revisi terdekat ke tanggal itu. Ia tidak akan pernah mengembalikan objek, jadi ia harus selalu kembali 200 OK. Bahkan jika ini dapat mengambil rentang tanggal, dan logikanya adalah untuk mengembalikan semua objek dalam jangka waktu itu kembali 200 OK - 0 Hasil ok, karena itulah permintaan untuk - set hal-hal yang memenuhi kriteria itu.

Namun, yang terakhir berbeda karena Anda meminta objek tertentu , mungkin unik, dengan identitas itu. Kembali 200 OKdalam kasus ini salah karena sumber daya yang diminta tidak ada dan tidak ditemukan .

Mengenai memilih kode status

  • 2xx kode Beri tahu UA bahwa itu melakukan hal yang benar , permintaan itu berhasil. Itu bisa terus melakukan ini di masa depan.
  • Kode 3xx Beri tahu UA apa yang Anda minta mungkin dulu berfungsi, tetapi benda itu sekarang ada di tempat lain. Di masa depan UA mungkin mempertimbangkan untuk pergi ke redirect .
  • Kode 4xx Beri tahu UA bahwa ia melakukan kesalahan , permintaan yang dibuatnya tidak layak dan tidak boleh mencobanya lagi, tanpa setidaknya beberapa modifikasi.
  • 5xx kode Memberitahu UA server rusak entah bagaimana . Namun, kueri itu dapat berfungsi di masa mendatang, jadi tidak ada alasan untuk tidak mencobanya lagi. (kecuali untuk 501, yang lebih dari masalah 400).

Anda disebutkan dalam komentar menggunakan kode 5xx, tetapi sistem Anda berfungsi. Itu ditanya pertanyaan yang tidak berfungsi dan perlu mengomunikasikannya ke UA. Tidak peduli bagaimana Anda mengirisnya, ini adalah wilayah 4xx.

Pertimbangkan alien yang menanyakan tata surya kita

Alien: Komputer, tolong beri tahu saya semua planet yang dihuni manusia.

Komputer: 1 hasil ditemukan. Bumi

Alien: Komputer, tolong beri tahu saya tentang Bumi .

Komputer: Bumi - Kebanyakan Tidak Berbahaya.

Alien: Komputer, tolong beri tahu saya tentang semua planet yang dihuni manusia, di luar sabuk asteroid.

Komputer: 0 hasil ditemukan.

Alien: Komputer, tolong hancurkan Bumi.

Komputer: 200 OK.

Alien: Komputer, tolong beri tahu saya tentang Bumi .

Komputer: 404 - Tidak Ditemukan

Alien: Komputer, tolong beri tahu saya semua planet yang dihuni manusia.

Komputer: 0 hasil ditemukan.

Alien: Kemenangan untuk Kekaisaran Irken yang perkasa!


4
+1 Ini bukan kueri yang tidak menghasilkan apa-apa. Ini seperti meminta browser untuk halaman web yang dikenal dan tidak menemukannya. Untuk apa 404 itu ada.
Andres F.

2
@ imel96 Anda lupa bahwa string kueri adalah bagian dari URL.
Loïc Faure-Lacroix

1
@LegoStormtroopr Contoh "alien" Anda yang lucu bekerja karena alam semesta BUKAN tidak valid ketika Bumi tidak ada. Tetapi sesuai penjelasan OP, sistemnya harus menyertakan pohon. Tanpa pohon, sistem tidak berfungsi.
Andres F.

1
@LegoStormtroopr bayangkan tabel database. Anda kueri tabel, kadang-kadang Anda mendapatkan hasil, kadang-kadang tidak. Tabel adalah sumber Anda, selalu ada di sana, terlepas dari baris yang dikembalikan atau tidak. Tabel dapat diidentifikasi, memiliki nama (seperti sumber daya http memiliki URI). Baris tidak, mereka hanya cocok dengan beberapa parameter. Bahkan dalam database, jika Anda melakukan pembaruan yang tidak cocok dengan apa pun, Anda akan mendapatkan "OK 0 rows terpengaruh".
imel96

2
@LegoStormtroopr Anda sudah memiliki jawabannya. Jika mereka ingin memetakan ulang / GoalTree / GetById? VersionId = x, maka itu harus mengembalikan 301 dengan header Lokasi diatur ke / GoalTree / Id / x.
imel96

11

Mengabaikan fakta bahwa / GoalTree / Get * terlihat seperti kata kerja, bukan sumber daya, Anda harus selalu mengembalikan 200 karena URI / GoalTree / Get * mewakili sumber daya yang selalu tersedia untuk diakses dan itu bukan kesalahan klien jika tidak ada pohon sebagai akibat dari permintaan. Kembalikan 200 dengan set kosong ketika tidak ada entitas yang akan dikembalikan.

Anda menggunakan 404 jika sumber daya tidak ditemukan, bukan ketika tidak ada entitas.

Masukkan dengan cara lain, jika Anda ingin mengembalikan 404 untuk objek Anda, maka berikan URI mereka sendiri.


1
Hmm. Ini masuk akal. 404 adalah kesalahan pengguna , tetapi seperti yang dijelaskan OP, ini sebenarnya adalah kesalahan sistem ; permintaan pengguna benar-benar valid! Saya tidak setuju 200 adalah respon yang tepat, karena "tidak ada pohon" adalah kesalahan .
Andres F.

@ imel96 Saya lebih suka memiliki entitas yang valid selalu dikembalikan bukannya kosong / kode status 4xx / 5xx. Jika itu hanya saya, saya akan mengembalikan entitas yang valid seperti wiki misalnya. Kurang sakit kepala tidak perlu menangani kesalahan. Seperti itu, saya akan mengatakan itu hampir seperti 500. Sistem dalam keadaan tidak terdefinisi, seharusnya tidak terjadi. Dan kembali OK tidak masuk akal. 404 tentang rfc juga tidak masuk akal. Jadi ketika tidak ada yang masuk akal ... hanya 500 yang masuk akal!
Loïc Faure-Lacroix

@ Sibiam juga, Anda meminta kode status http yang didefinisikan dengan sangat baik. Dalam hal ini, bahkan jika logika bisnis Anda mengatakan itu kesalahan, itu tidak berarti sistem sebagai server http memiliki kesalahan. Dalam kasus Anda, itu memahami permintaan Anda, itu memproses permintaan Anda dan kebetulan hasilnya adalah tidak ada entitas. Jadi Anda juga tidak bisa menggunakan 500. Setidaknya pertimbangkan untuk memberikan objek Anda URI yang tepat dan lihat apakah rfc lebih masuk akal atau tidak.
imel96

+1 Jika Anda memiliki API REST (setiap entitas memiliki jalurnya sendiri) maka Anda dapat mengembalikan 404, tetapi jalur Anda adalah kata kerja dan akan selalu ditemukan.
Stop Harming Monica

@OrangeDog: /GoalTree/GetById?versionId=12345 adalah URI yang sangat bagus (well, relatif, setidaknya) yang mengidentifikasi sumber daya tertentu, yaitu data yang terkait dengan ID versi 12345dalam sistem. Jika tidak ada data dengan ID seperti itu, respons HTTP 404 sangat tepat. Tentu saja, badan respons harus, dalam hal apa pun, berisi respons yang diformat dengan tepat (misalnya JSON, jika itu yang diharapkan oleh klien yang meminta sumber daya semacam itu) yang mengindikasikan sifat spesifik dan penyebab kesalahan.
Ilmari Karonen

7

Ini adalah pertanyaan yang menarik, karena ini semua tentang spesifikasi sistem.

Tanggapan imel96 telah meyakinkan saya bahwa 404 tidak akan menjadi respons yang tepat, karena keluarga kode 4xx terutama untuk kesalahan pengguna / klien , dan ini bukan salah satunya. URL terbentuk dengan baik dan pohonnya harus ada di sana; jika tidak, sistem dalam keadaan tidak konsisten!

Oleh karena itu ini adalah kesalahan server , yaitu sesuatu dalam keluarga 5xx. Mungkin 500 Server Internal Kesalahan generik atau Layanan 503 Tidak Tersedia (layanan sedang "menjemput saya pohon yang harus ada di sana").


2
Tidak benar, pengguna salah karena mereka meminta sesuatu yang tidak ada .

@LegoStormtroopr Meminta sesuatu yang tidak ada tidak selalu merupakan kesalahan. Jika Anda meminta sumber daya jaringan, dan jaringan sedang down, maka itu merupakan kesalahan jaringan .
Andres F.

1
@LegoStormtroopr Selain itu, pohon itu harus ada; sistem tidak dapat berfungsi tanpanya, sesuai penjelasan OP. Karena itu, sah untuk meminta sumber ini; jika tidak ada, itu pasti kesalahan sistem (atau server).
Andres F.

2
@ Sibiam Jika Anda akan pergi rute kode 5xx, 503 adalah "503 Layanan Tidak Tersedia - Server saat ini tidak dapat menangani permintaan karena kelebihan sementara atau pemeliharaan server." Server Anda tidak kelebihan beban, tidak menemukan permintaan. Selain itu, kode 5xx adalah untuk ketika "server menyadari bahwa ia telah melakukan kesalahan atau tidak mampu melakukan permintaan"

1
@AndresF. Sejujurnya, kode 500 mungkin baik-baik saja. Mengingat bagaimana pertanyaan telah berubah seiring waktu, itu akan berhasil. Sebagian besar, saya hanya berusaha melawan mengembalikan 200 jika semuanya tidak beres.

6

Saya akan mengatakan bahwa kode respons 200 atau 404 dapat valid , tergantung pada bagaimana Anda melihat situasi.

Masalahnya adalah bahwa kode respons HTTP didefinisikan dalam konteks server , yang dapat memberikan berbagai sumber daya berdasarkan URL mereka. Dalam konteks ini, makna 200 OKdan 404 Not Foundsama sekali tidak ambigu: yang pertama mengatakan "inilah sumber daya yang Anda minta", sedangkan yang kedua mengatakan "maaf, saya tidak punya sumber daya seperti itu".

Namun, dalam situasi Anda, Anda memiliki lapisan aplikasi tambahan antara server HTTP dan sumber daya aktual (pohon) yang diminta. Aplikasi ini menempati semacam ruang perantara yang tidak ditangani dengan baik dalam spesifikasi HTTP.

Dari sudut pandang webserver ini, aplikasi terlihat jenis seperti sumber daya: itu biasanya file di server, diidentifikasi oleh (bagian dari) URL, seperti sumber daya lainnya (misalnya file statis) server mungkin melayani. Di sisi lain, ini adalah jenis sumber daya yang aneh, karena terdiri dari kode yang dapat dieksekusi yang secara dinamis menentukan konten, dan memang berpotensi bahkan kode status, dari respons, membuatnya berperilaku dalam beberapa hal lebih seperti mini-server.

Khususnya, dalam contoh kasus Anda, server web dapat menemukan aplikasi dengan baik, tetapi aplikasi kemudian gagal menemukan sumber daya (pohon) yang telah diminta. Sekarang, jika Anda menganggap aplikasi hanya sebagai perpanjangan dari server , dan subitem (pohon) sebagai sumber daya aktual, maka respons 404 sesuai: server hanya mendelegasikan tugas menemukan sumber daya aktual ke aplikasi , yang ternyata gagal melakukannya.

Di sisi lain, jika sudut pandang Anda adalah bahwa aplikasi adalah sumber daya yang diminta, maka jelas server web harus mengembalikan respons 200 ; setelah semua, aplikasi ditemukan dan dieksekusi dengan benar. Jelas, dalam kasus ini, aplikasi harus mengembalikan badan tanggapan yang valid dalam format yang diharapkan, yang menunjukkan (menggunakan protokol tingkat tinggi apa pun yang diformat), bahwa tidak ada data aktual yang cocok dengan kueri yang ditemukan.

Kedua sudut pandang ini bisa masuk akal. Dalam kebanyakan kasus , setidaknya untuk aplikasi yang dimaksudkan untuk dapat langsung diakses melalui HTTP dengan browser web biasa, saya akan mendukung pandangan sebelumnya : pengguna umumnya tidak peduli tentang detail internal seperti perbedaan antara server dan aplikasi, mereka hanya peduli apakah data yang mereka inginkan ada atau tidak.

Namun, dalam kasus spesifik aplikasi yang dirancang untuk berkomunikasi dengan program komputer lain menggunakan protokol API tingkat tinggi khusus, menggunakan HTTP hanya sebagai lapisan transport level rendah , ada argumen yang dibuat untuk mendukung tampilan terakhir : untuk klien yang berinteraksi dengan aplikasi semacam itu, yang benar-benar mereka pedulikan, pada tingkat HTTP , adalah apakah mereka berhasil menghubungi aplikasi tersebut atau tidak. Segala sesuatu yang lain, dalam kasus seperti itu, seringkali lebih dikomunikasikan secara alami menggunakan protokol tingkat yang lebih tinggi.


Bagaimanapun, terlepas dari pandangan mana di atas yang Anda sukai, ada beberapa detail yang harus Anda ingat. Salah satunya adalah bahwa, dalam banyak kasus, mungkin ada perbedaan yang berarti antara sumber daya (dasarnya) kosong dan sumber daya yang tidak ada .

Pada tingkat HTTP, sumber daya kosong hanya akan ditunjukkan oleh kode respons 200 dan badan respons kosong, sedangkan sumber daya tidak ada akan ditunjukkan oleh respons 404 dan badan sumber daya menjelaskan tidak adanya sumber daya. Dalam protokol API tingkat yang lebih tinggi, seseorang biasanya akan menunjukkan sumber daya yang tidak ada oleh respons kesalahan, yang berisi kode / pesan kesalahan spesifik protokol yang sesuai, sementara respons kosong hanya akan menjadi struktur respons normal tanpa item data.

(Perhatikan bahwa sumber daya tidak perlu secara harfiah nol byte panjang untuk menjadi "kosong" dalam arti yang saya maksud di atas. Misalnya, hasil pencarian tanpa item yang cocok akan dihitung sebagai kosong dalam arti luas, seperti halnya hasil kueri SQL dengan tidak ada baris atau dokumen XML yang tidak mengandung data aktual.)

Juga, tentu saja, jika aplikasi benar-benar percaya bahwa subresource diminta harus berada di sana, tetapi tidak dapat menemukannya, maka kode respon ketiga yang mungkin ada: 500 Internal Server Error. Respons semacam itu masuk akal jika keberadaan sumber daya dianggap sebagai prasyarat untuk aplikasi, sehingga ketidakhadirannya mengindikasikan kerusakan internal.

Akhirnya, Anda harus selalu mengingat hukum Postel :

" Jadilah konservatif dalam apa yang Anda kirim, dan liberal dalam apa yang Anda terima. "

Apakah server harus merespons dalam situasi tertentu dengan respons 200 atau 404, itu tidak memaafkan Anda sebagai pelaksana klien dari penanganan respons yang tepat dan dengan cara yang memaksimalkan interoperabilitas yang kuat. Tentu saja, apa arti penanganan yang "tepat" dalam situasi yang berbeda dapat diperdebatkan, tetapi hal itu tentunya tidak seharusnya termasuk menabrak atau "berantakan".


Dilema itu dijelaskan dengan baik.
Marcel

tidak ada dilema. jawaban ini tidak didasarkan pada sumber daya apa yang didefinisikan dalam rfc terkait. lihat komentar saya di bawah jawaban @LegoStormtroopr.
imel96

@ imel96: Saya pikir Anda salah menafsirkan RFC 1630: paragraf yang Anda kutip dalam komentar Anda sebelumnya berbunyi, secara lengkap: "Tanda tanya ("? ", ASCII 3F hex) digunakan untuk membatasi batas antara URI yang dapat ditanyakan. objek, dan satu set kata yang digunakan untuk mengekspresikan permintaan pada objek itu. Ketika formulir ini digunakan, URI gabungan singkatan dari objek yang dihasilkan dari permintaan yang diterapkan ke objek asli. " (penekanan tambang). Dengan demikian, jelas bahwa string kueri memang merupakan bagian dari URI (meskipun bagian sebelum string kueri, tentu saja, juga URI yang valid dengan sendirinya) ...
Ilmari Karonen

... dan gabungan URI ini mengidentifikasi sumber daya tertentu yang dapat diminta oleh klien dengan mengirimkan URI itu ke server. Dalam kasus apa pun, RFC 2616 (HTTP) hanya mendefinisikan sumber daya sebagai "Objek data jaringan atau layanan yang dapat diidentifikasi oleh URI, sebagaimana didefinisikan dalam bagian 3.2." dan selanjutnya mengatakan bahwa "Sejauh menyangkut HTTP, Uniform Resource Identifiers hanyalah string yang diformat yang mengidentifikasi - melalui nama, lokasi, atau karakteristik lainnya - sumber daya."
Ilmari Karonen

@IlmariKaronen kamu benar. Saya bingung HTTP dengan REST. Meski begitu sepertinya masih tidak benar karena saya tidak yakin apa yang dapat Anda lakukan dengan sumber daya dengan URI seperti / GoalTree / Get? VersionDate =
2000BC

3

Bagaimana dengan 204 Tidak Ada Konten? Itu akan menyarankan bahwa permintaan Anda berhasil diproses tetapi tidak mengembalikan apa pun. Ini masih "sukses" tetapi memungkinkan Anda untuk melihat apakah Anda memiliki hasil berdasarkan kode status saja.


6
jika Anda membaca spesifikasi lebih lanjut, "Respons ini terutama dimaksudkan untuk memungkinkan input untuk tindakan terjadi tanpa menyebabkan perubahan pada tampilan dokumen aktif agen pengguna". Jadi itu tidak boleh digunakan untuk permintaan GET.
imel96

3

Jika URL mewakili sumber daya yang tidak pernah ada, kembalikan 404 Tidak Ditemukan

Jika URL mewakili sumber daya, daftar kosong akan mengembalikan daftar kosong dan 200 OK.

Contoh:

{
  total: 0,
  items: []
}

Jika URL mewakili sumber daya yang dulunya ada kembali, 410 Hilang.

Mengenai dialog Lego Stormtrooper:

Alien: Computer, please tell me all planets that humans inhabit. GET /planets?inhabitedBy=humans

Computer: 200 OK. { total: 1, items:[{name:'Earth'}] }

Alien: Computer, please tell me about Earth. GET /planets/earth

Computer: 200 OK. {name:'Earth', status: 'Mostly Harmless'}

Alien: Computer, please tell me about all planets humans inhabit, outside the asteroid belt. GET /planets?inhabitedBy=humans&distanceFromSun=lots

Computer: 200 OK. {total:0, items:[] }

Alien: Computer, please destroy Earth. DELETE /planets/earth

Computer: 204 No Content. (or 202 Accepted if it takes some time to destroy Earth)

Alien: Computer, please tell me about Earth. GET /planets/earth

Computer: 410 Gone

Alien: Computer, please tell me all planets that humans inhabit. GET /planets?inhabitedBy=humans

Computer: 200 OK 0 {total: 0, items:[] }

Alien: Victory for the mighty Irken Empire!

1

Dari suaranya, ini adalah API untuk penggunaan internal . Hal ini memberikan keunggulan dalam menggunakan skema mana saja yang memberikan manfaat paling besar , terlepas dari apakah itu sesuai dengan buku (spesifikasi) atau tidak. Ini tidak berarti sepenuhnya menciptakan kode status Anda sendiri, tetapi tidak apa-apa untuk 'membengkokkan' aturan sedikit jika itu bermanfaat.

Saya setuju dengan pendirian Anda bahwa Anda harus mendapatkan kode status yang menunjukkan ada kesalahan. Lagipula ini adalah untuk apa kode status. Anda juga mendapatkan manfaat dari perpustakaan yang memberikan pengecualian / dll. pada kode status non-200 sehingga Anda tidak perlu memeriksa secara eksplisit (Atau Anda dapat menulis bungkus Anda sendiri yang melakukan ini).

Saya juga setuju dengan sudut pandang Andres F. bahwa 500 sesuai karena pohon itu seharusnya ada. Namun dalam praktiknya, saya suka membagi kesalahan server menjadi dua kategori. Sesuatu yang tidak terduga menjadi salah dan sesuatu yang secara praktis dapat saya periksa salah. Ini menghasilkan kode status berikut,

  • 200 - Semuanya baik
  • 404 - Url salah
  • 409 - Ada yang salah
  • 500 - Kesalahan tak terduga terjadi di server

Dalam kasus khusus Anda, Anda dapat memeriksa apakah pohon ada atau tidak di sisi server dan jika tidak ada maka kembalikan 409. Ini adalah kesalahan yang diharapkan (Anda tahu itu bisa terjadi, Anda bisa memeriksanya, dll.) . 409 konflik hanyalah preferensi pribadi saya, 5xx mungkin juga sesuai selama Anda dapat duduk dan memutuskan ini dengan tim Anda.

Mengkategorikan kode seperti ini membantu Anda lebih cepat mengidentifikasi jenis kesalahan, tetapi dapat memiliki manfaat di luar organisasi. Seringkali dengan kesalahan situs web Anda tidak ingin klien mendapatkan kesalahan yang tidak terduga karena ini bisa menjadi masalah keamanan dan mengungkapkan kerentanan sehingga Anda mengembalikan 500 generik "Terjadi kesalahan." dan catat kesalahan penuh di server. Tetapi jika kesalahan yang diharapkan terjadi sebagai 409 Anda tahu bahwa itu akan aman untuk menunjukkan kesalahan kepada klien dan Anda tidak harus meninggalkan mereka dalam kegelapan tentang apa yang terjadi. Ini hanya salah satu penggunaan praktis yang bisa saya ceritakan, tetapi ada banyak kemungkinan.

Ini sedikit menarik karena Anda memposting ini karena tidak bisa setuju dengan rekan kerja Anda, tetapi sepertinya Anda lebih banyak berdebat tentang semantik dan siapa yang secara politis benar. Tidak masalah siapa yang lebih pantas, selama Anda dapat menemukan sistem yang paling menguntungkan perusahaan.

Di sisi lain jika ini adalah API publik yang mengikuti spesifikasi sedekat mungkin akan lebih penting untuk menghindari kebingungan di antara masyarakat.


0

Mengambil langkah singgung pada hal ini: Jika seorang manusia akhirnya menggunakan API (melalui GUI) saya akan menyarankan melakukan apa pun yang membuat hidup mudah bagi pengguna akhir. Tidak adanya pohon ketika seharusnya ada adalah kesalahan "Domain model inconsistency". Kesalahan sistem adalah ketika Anda kehabisan memori atau mengalami beberapa kegagalan sistemik lainnya. Jadi mengembalikan 5xx tidak pantas. Seperti yang disebutkan oleh beberapa orang di atas, 4xx mungkin sesuai jika pohon itu sendiri memiliki URI sendiri, yang tidak terjadi di sini. Tapi inilah yang dikatakan 404 kepada klien: Anda dapat mencoba lagi dan lagi sampai Anda mendapatkan sesuatu kembali. Jika Anda mengembalikan 200, Anda dapat mengembalikan diagnostik yang cukup ke pengguna atau agen pengguna sehingga agen pengguna dapat menampilkan meaaage sehingga pengguna berhenti mencoba kembali dan hanya mendukung kontak. Di sisi lain jika API ini hanya ditujukan untuk sistem,


404 yang benar-benar dikatakan adalah "benda itu tidak ada di sini, dan saya tidak tahu di mana benda itu berada". 3xx dan 5xx tidak masalah untuk mencoba ulang. Tetapi 4xx mengatakan, "permintaan Anda saat ini tidak cukup bagi saya untuk menemukan antyhing untuk Anda. Silakan pergi."

Saya suka kemungkinan untuk membedakan antara URL TIDAK DITEMUKAN dan Sumber Daya TIDAK DITEMUKAN ... Jadi Titik Akhir Layanan sudah aktif dan berjalan 200, namun sumber daya yang diminta TIDAK DITEMUKAN 404 (Badan Respons).
Limun
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.