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

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!

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.

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").

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".

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.

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!

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.

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,