Apa yang seharusnya menjadi kode status http untuk kesalahan "Layanan tidak tersedia di wilayah Anda"?

51

Layanan kami ada di 5 kota sekarang. Jika seseorang mencoba memanggil API layanan kami dari kota lain, kami ingin membuang kesalahan ini Service not available in your area.

Pertanyaannya adalah, apa kode http yang sesuai untuk kesalahan ini?

  • 503 Layanan tidak tersedia
  • 403: Dilarang

atau sesuatu yang lain?

api api-design http Shaharyar
sumber
52
"Jika seseorang mencoba memanggil API layanan kami dari kota lain" perhatikan bahwa geolokasi IP sangat sering salah, jika Anda melarang pengguna yang geolokasi IP-nya ke kota lain, Anda kemungkinan besar akan mengunci pengguna yang sah.
Peter Green
43
Apakah saya tidak diizinkan untuk menumpang tumpangan untuk anak saya, yang berada di kota lain dan perlu datang ke bandara untuk mengunjungi saya?
Dawood mengatakan mengembalikan Monica
29
Meskipun bukan jawaban untuk pertanyaan, HTTP 451 (RFC 7725) mungkin bermanfaat bagi pembaca di masa mendatang yang menemukan pertanyaan ini. Tujuan utamanya adalah untuk menunjukkan bahwa konten tidak tersedia karena permintaan, tindakan, atau pembatasan hukum (hak cipta, perintah pengadilan, dll.)
Tyzoid
34
Jika tidak ada yang salah dengan konektivitas jaringan, otentikasi, tidak ada kesalahan secara internal dalam aplikasi, dan input yang valid secara sintaksis seharusnya tidak ada pesan kesalahan. Dengan "kami tidak menawarkan layanan kami di area ini" Anda telah meninggalkan masalah teknologi dan masuk ke masalah bisnis, jadi saya tidak yakin kesalahan HTTP akan sesuai. Saya pikir Anda harus memberikan 200 dan (atau 302 dan mengarahkan kembali ke) pesan yang sesuai tentang "maaf layanan kami belum tersedia di wilayah Anda - namun. Kami sedang memperluas - Periksa kembali pada akhir 2019!" atau apa pun yang muncul dari departemen pemasaran.
ivanivan
7
Tidak jelas dari pertanyaan apakah Anda bermaksud memblokir semua akses ke API berdasarkan lokasi komputer klien (geo IP?) Atau jika Anda meminta kode respons untuk permintaan API tertentu yang gagal (mis. Buku? Address = 123_example_st_london) . Apakah lokasi bagian dari input, atau apakah Anda memiliki lokasi klien dengan cara lain?
Ben

Jawaban:

101

Kode kesalahan HTTP apa pun tidak pantas. Tidak ada kesalahan atau masalah dalam bentuk apa pun dari perspektif HTTP sehingga harus ada dalam kisaran 200. Anda dengan sopan memberi tahu beberapa pengguna bahwa mereka tidak akan dilayani dengan mengirimkan kembali dokumen yang memberi tahu mereka. Dan ini semua berjalan dengan baik.

Pengguna tidak akan dapat menggunakan aplikasi Anda . Itu adalah keputusan sadar yang dibuat oleh logika bisnis Anda, bukan kecelakaan. Pada tingkat HTTP semuanya dory honky.

Sunting

Sepertinya yang kita lihat di sini adalah bentrokan antara sekolah lama dengan sekolah baru. Ketika HTTP dirancang, tidak ada layanan web, tidak ada SOAP, tidak ada JSON, tidak ada prinsip REST. Sebagai protokol di atas TCP ini sudah dianggap (dekat dengan) tingkat aplikasi dan banyak kode status tingkat tinggi didefinisikan. Ketika web mulai digunakan untuk layanan yang lebih kaya, tingkat tinggi dan sarana umum untuk mengangkut "amplop" diperlukan, para perancang meningkatkan HTTP daripada mendefinisikan protokol yang lebih baru dan lebih bersih, hanya karena HTTP ada di mana-mana.

Jadi dalam konteks layanan web modern, HTTP memang sedikit lebih dari lapisan transport yang bodoh dan sebagian besar kodenya mungkin dianggap tidak berlaku atau usang. Hanya memilih satu karena mendekati keadaan aplikasi Anda dan kebetulan berada di daftar itu yang pernah berarti sesuatu mungkin tampak tidak berbahaya, tapi saya pikir itu akan mengirim pesan yang salah. Anda tidak ingin HTTP memainkan peran yang mengatur dalam konteks layanan web.

Martin Maat
sumber
56
Dengan logika ini, kesalahan aplikasi apa pun harus dikembalikan sebagai 200. Dan semua permintaan harus POST, bahkan penghapusan. Pendekatan ini memperlakukan HTTP sebagai protokol transport yang tidak jelas - seperti TCP. Ini bukan bagaimana layanan web API biasanya diperlakukan - mereka mencoba untuk meningkatkan semantik HTTP dan bahasa standar untuk API. Mengapa tidak mengembalikan 401 untuk Tidak Sah, alih-alih mengembalikan 200 dengan kode kesalahan khusus dan tidak standar?
Avner Shahar-Kashtan
31
Dengan logika ini, tidak ada aplikasi yang seharusnya mengembalikan respons apa pun di kisaran 400. Inilah tepatnya jenis kondisi untuk kisaran 400 tanggapan. Juga, apakah kalimat pertama Anda berlaku untuk semua jawaban di masa depan, serta yang telah diposting sebelum Anda?
Dawood mengatakan mengembalikan Monica
31
Saya harus setuju di sini bahwa ini hanya 200 sederhana. Pengguna telah mengajukan pertanyaan, kami memahaminya, kami tahu jawaban yang benar, dan kami telah memberinya jawaban (yang kebetulan adalah "Tidak"). Semua baik-baik saja di tanah HTTP.
Lee Daniel Crocker
8
Hehe ... perjalanan cepat dari "ini bukan benar-benar kesalahan" ke "jadi, Anda mengatakan tidak ada yang pernah kesalahan?"
svidgen
28
Ini. "Anda mencoba mengakses URL yang tidak ada" sangat berbeda dari "Perusahaan kami tidak beroperasi di wilayah Anda". Hanya satu yang ada hubungannya dengan HTTP.
CJ Dennis
87

5xxkesalahan adalah kesalahan server - ada yang salah di server. Secara khusus, 503 menunjukkan bahwa:

server saat ini tidak dapat menangani permintaan karena kelebihan sementara atau pemeliharaan terjadwal

4xxkesalahan adalah kesalahan klien - klien membuat permintaan bahwa server tidak dapat atau tidak mau memenuhi. Secara khusus, 403 menunjukkan itu

server memahami permintaan tersebut tetapi menolak untuk mengesahkannya. Server yang ingin mengumumkan kepada publik mengapa permintaan itu dilarang dapat menggambarkan alasan itu dalam payload respons (jika ada). [..] Namun, permintaan mungkin dilarang karena alasan yang tidak terkait dengan kredensial.

Saya berpendapat bahwa 503itu jelas salah, karena ini bukan masalah sementara - Anda tidak mendukung permintaan di daerah itu, titik. Argumen dapat dibuat bahwa Anda akhirnya berharap untuk mendukung area tersebut, tetapi maksud kode adalah untuk menyertakan header yang menunjukkan kapan klien dapat mencoba lagi. "Dalam 6 bulan" tidak sesuai dengan niat.

403 adalah pilihan yang lebih baik karena layanan Anda hanya melarang permintaan dari lokal tertentu.

Eric Stein
sumber
403 adalah untuk kasus-kasus di mana akses dilarang, dan klien tidak dapat berbuat apa-apa. Tetapi dalam hal ini klien dapat (masuk mobil dengan laptop atau telepon Anda), jadi 403 tidak pantas.
gnasher729
2
@ gnasher729 Kesalahan 4xx adalah untuk hal-hal yang mungkin dapat diperbaiki oleh klien, termasuk 403. Spesifikasi (ditautkan) secara khusus menyatakan klien dapat mencoba ulang dengan kredensial yang berbeda (dengan asumsi kredensial adalah masalahnya).
jaxad0127
22
@ gnasher729 403 tidak berarti manusia tidak bisa berbuat apa-apa. Ini berarti browser tidak dapat berbuat apa-apa. Manusia selalu dapat melakukan reset kata sandi, berbicara dengan administrator atau dalam hal ini pindah ke kota lain.
slebetman
1
@ gnasher729 Klien bukan pengguna.
Kapten Man
10
5xx = Ups masalah buruk kami, tunggu sebentar sementara kami memperbaiki masalahnya. 4xx = Kami minta maaf tetapi berdasarkan kebijakan kami tidak dapat mengakomodasi permintaan Anda saat ini. Inilah sebabnya ....
candied_orange
46

Tak satu pun dari itu.

Jika API Anda dirancang dengan baik, URL menyertakan nama kota, mis

http://example.com/API/Vienna/HailRide

atau

http://example.com/API/HailRide?city=Vienna

karena geolokasi IP tidak dapat diandalkan, pengguna Anda mungkin menggunakan VPN, pengguna Anda mungkin ingin naik tumpangan untuk orang lain, dll. Menyarankan kota berdasarkan lokasi pengguna adalah tanggung jawab klien API . Biasanya, klien memiliki sumber daya yang jauh lebih baik untuk menentukan lokasi pengguna (misalnya, layanan lokasi perangkat seluler).

Setelah Anda selesai melakukannya, jawaban yang benar untuk 

http://example.com/API/SomeUnsupportedCity/HailRide

atau

http://example.com/API/HailRide?city=SomeUnsupportedCity

menjadi jelas: 404 Tidak Ditemukan : Tidak ada sumber daya untuk memanggil tumpangan di SomeUnsupportedCity ada.

Heinzi
sumber
6
Ini harus menjadi jawaban yang diterima: desain API tidak hanya tentang mematuhi kode numerik lama, dan skenario tentang vpn dll cukup realistis.
Edoardo
10
Saya harus tidak setuju dengan ini. Memasukkan nama kota di URL dapat menyebabkan segala macam masalah di jalan, karena memaksa klien untuk menentukan nama kota berdasarkan lokasi, dan Anda mungkin tidak menyukai hasilnya. Misalnya, apakah Anda di Los Angeles atau Beverly Hills? London atau Westminster? Apa yang terjadi jika klien berpikir itu ada di Richardson, tetapi Anda menginginkan API untuk melayani seluruh area Dallas? Ini akan menjadi ide yang lebih baik bagi klien untuk hanya memasok lokasi pickup / dropoff; server dapat menentukan apakah mereka berada dalam area layanan dan merespons sesuai.
Zach Lipton
11
@ZachLipton Saya cukup yakin nama-nama kota adalah contoh saja, itu tergantung pada aturan bisnis OP yang sebenarnya bagaimana mereka mendefinisikan "kota" atau "lokasi". Itu juga bisa menjadi koordinat.
Bergi
1
@ ZachLipton tidak, intinya di sini adalah tidak memiliki layanan menggunakan IP klien untuk memahami lokasi, itu hanya salah
Edoardo
3
@ eddyce Saya setuju bahwa menggunakan IP klien adalah ide yang buruk karena berbagai alasan. Saya mengatakan bahwa / API / Vienna / HailRide juga rentan terhadap masalah, karena itu mengharuskan klien untuk mengubah lokasi menjadi nama kota, dan itu bukan pemetaan 1-ke-1 yang sesuai dengan area yang perusahaan lakukan.
Zach Lipton
26

Ini sepertinya pertanyaan pasak hole / square round. Mengapa satu-satunya tanggapan Anda harus berupa kode HTTP? Kode kesalahan HTTP tidak mungkin mencakup semua kasus penggunaan.

Semua panggilan API Anda harus memiliki pesan tambahan yang muncul kembali - yaitu pesan kesalahan JSON kecil. Beri mereka 403 (karena, mereka benar-benar tidak memiliki izin untuk menggunakan API yang diberikan lokasi) dan mengembalikan sedikit informasi tambahan seperti yang Anda sarankan.

Jika Anda tidak melakukan ini maka lain kali Anda akan menanyakan kode kesalahan HTTP apa yang akan dikembalikan ketika pengguna meminta sebuah SUV tetapi hanya Prius yang tersedia.

stdunbar
sumber
5
+1 untuk kalimat terakhir Anda. Ringkas dengan baik.
LoztInSpace
1
Nah itu cukup jelas perlu 3xx redirect dari beberapa jenis. ;)
Nama Asli Dihilangkan
Kasus terakhir mungkin menjamin respons 4xx semacam: pengguna membuat permintaan yang tidak dapat dipenuhi oleh server. Ini akan menjadi 400 jika pilihannya adalah jenis input yang tidak valid atau 404 jika lokasi itu sendiri tidak ada. Meskipun bisa 200 jika itu kriteria pencarian dan tidak ada kecocokan.
jpmc26
11

Beberapa masuk akal.

403 Forbidden, untuk alasan yang disebutkan oleh Eric Stein dalam jawabannya . Anda dapat menggunakan berbagai informasi yang disediakan oleh permintaan untuk menentukan di mana klien berada dan siapa klien itu dan, berdasarkan permintaan itu, server tidak dapat atau tidak mau menanggapi.

Namun, saya juga akan mengajukan 451 Tidak Tersedia untuk Alasan Hukum sebagai status pengembalian yang mungkin untuk beberapa kasus. Status ini mengharapkan Anda untuk memasukkan (dalam tajuk) tautan ke undang-undang yang relevan. Khususnya untuk kasus-kasus di mana klien tidak boleh mengakses sumber daya Anda, dan bukan kasus klien yang lebih umum ada di wilayah atau wilayah yang tidak didukung.

Saya akan menghindari serangkaian status 5xx - ini sering menunjukkan masalah teknis sisi server. Tampaknya tidak demikian di sini.

Thomas Owens
sumber
Mungkin alasan dalam hal ini adalah bahwa tidak masuk akal untuk memberi tahu pengguna tentang mobil yang tidak ada di kota mereka. Jadi tidak demikian halnya untuk 451
max630
4
@ max630 Anda tidak dapat menganggap itu dari pertanyaan. 403 Terlarang kemungkinan besar adalah pilihan yang tepat. Namun, jika ada batasan hukum pada layanan, 451 yang lebih spesifik dapat digunakan sebagai gantinya. 451 sering dilihat sebagai versi 403 yang lebih spesifik untuk kasus penggunaan yang sangat khusus, jadi masuk akal untuk membawanya.
Thomas Owens
8
@ max630 - sangat memungkinkan bahwa 451 sesuai di sini. Banyak yurisdiksi mengharuskan operator dari jenis layanan ini untuk didaftarkan pada otoritas regional sebelum menyediakan layanan. Mereka sebenarnya dapat secara hukum dilarang memproses permintaan tertentu jika mereka berasal dari luar daerah.
Jules
5

Jika pembatasan ini karena alasan hukum, maka kode kesalahan HTTP yang sesuai adalah HTTP 451, "Tidak tersedia karena alasan hukum."

Ini biasanya digunakan dalam kasus materi yang telah dicabut karena tindakan DMCA atau tuntutan hukum karena kampanye pelecehan atau sejenisnya, tetapi semangat dan surat definisi tanggapan menyatakan:

Dokumen ini menetapkan kode status Hypertext Transfer Protocol (HTTP) untuk digunakan ketika akses sumber daya ditolak sebagai konsekuensi dari tuntutan hukum.

Kode itu sendiri adalah referensi ke Fahrenheit 451 oleh Ray Bradbury.

halus
sumber
3

Orang sering lupa bahwa kode status HTTP dapat diperpanjang.

Kode status HTTP dapat diperpanjang. Aplikasi HTTP tidak diperlukan untuk memahami arti dari semua kode status terdaftar, meskipun pemahaman seperti itu jelas diinginkan. Namun, aplikasi HARUS memahami kelas kode status apa pun, seperti ditunjukkan oleh digit pertama, dan memperlakukan setiap respons yang tidak dikenal sebagai setara dengan kode status x00 kelas itu, dengan pengecualian bahwa respons yang tidak dikenal HARUS TIDAK di-cache. Misalnya, jika kode status 431 yang tidak dikenali diterima oleh klien, ia dapat dengan aman mengasumsikan bahwa ada sesuatu yang salah dengan permintaannya dan memperlakukan respons seolah-olah telah menerima 400 kode status. Dalam kasus seperti itu, agen pengguna HARUS hadir untuk pengguna entitas yang dikembalikan dengan respons,

https://tools.ietf.org/html/rfc2616#section-6.1.1

Anda selalu dapat hanya membuat kode status Anda sendiri dalam kisaran 400 untuk digunakan oleh API dan aplikasi klien Anda.

Bebek karet
sumber
Hmm ... mungkin tidak perlu jika permintaan menyertakan Expect token;city="Albequerque"header. Maka respons yang paling tepat adalah 417, harapan gagal. tools.ietf.org/html/rfc2616#section-10.4.18 Dengan asumsi tentu saja ini untuk layanan web.
Berin Loritsch
Mungkin tidak perlu @BerinLoritsch, tetapi daripada mencoba memaksakan situasi yang sesuai dengan kode yang ada, mungkin lebih baik hanya menyepak dan menggunakan yang khusus.
RubberDuck
0

Pada awalnya saya pikir 503 karena deskripsi "layanan tidak tersedia" tampaknya selaras dengan masalah tetapi melihat definisi , 503 benar-benar spesifik untuk tidak tersedianya server. Kemudian berpikir lebih banyak, Anda memberi tahu klien bahwa ada masalah dengan permintaan tersebut, bukan karena ada masalah sisi server.

403 lebih dekat karena Anda memberi tahu pengguna bahwa Anda menerima pesan dan memahaminya tetapi server tidak mau memenuhinya. Ini mungkin membingungkan sehingga penjelasan tekstual dapat ditambahkan untuk menggambarkan skenario. Per RFC, 404 juga merupakan pengganti yang valid untuk kode ini.

Kecuali seseorang telah memimpikan kode baru untuk ini, 403 atau 404 tampaknya yang paling dekat.

JimmyJames
sumber
Jelas bukan kode 5xx, karena itu menyiratkan bahwa mencoba permintaan yang sama persis nanti mungkin berhasil. Kode 4xx pasti memberi tahu klien untuk tidak mencoba lagi tanpa mengubah setidaknya sebagian dari permintaan (dalam hal ini, bidang "lokasi layanan").
Toby Speight
0

Anda harus mencocokkan deskripsi kesalahan dengan kode yang Anda berikan:

  • jika Anda berkata Service not available in your area.maka Anda harus memberi 404karena Anda mengklaim bahwa layanan tidak tersedia .

  • jika Anda berkata You are not authorized for this service in your area.maka Anda harus memberi 403karena Anda mengklaim bahwa penelepon tidak berwenang .

Saya akan memilih yang kedua.

Edoardo
sumber
6
404 bukan tentang ketersediaan , ini tentang keberadaan . Hanya karena layanan tidak tersedia dalam beberapa keadaan, Anda seharusnya tidak memberikan respons 404 kecuali Anda ingin orang-orang percaya bahwa itu tidak ada sama sekali. Respons 404 akan menjadi tidak berarti untuk situasi ini.
Jules
@jules Menurut spesifikasi untuk 403 (yang mungkin ketinggalan zaman): "Jika server tidak ingin membuat informasi ini tersedia untuk klien, kode status 404 (Tidak Ditemukan) dapat digunakan sebagai gantinya. " penekanan saya. Jadi jika 403 baik-baik saja, maka 404 juga akan, tetapi tidak harus karena alasan yang diberikan.
JimmyJames
@ JimmyJames - ya, itu dalam spesifikasi, tetapi merupakan ide yang sangat buruk karena membuat masalah debug sangat sulit. Bukan yang Anda inginkan di API.
Jules
3
@ Jules Layanan ini tidak ada di beberapa daerah. Sama seperti ada banyak toko kecil yang hanya ada di kota saya, jadi menanyakan alamat mereka di kota lain jawaban yang benar adalah "tidak ada."
Andy
ehmm berbicara tentang "keberadaan" tentang jalur url layanan adalah yang paling - filosofis, demi kejelasan setelah Anda menerbitkan jalan Anda harus memberikan jawaban, 403 adalah cara untuk pergi dalam kasus ini, dengan semacam deskripsi verbal dari situasi.
Edoardo
0

Ada Internet-Draft saat ini (yang akan berakhir pada 31 Desember 2018) yang mengusulkan amandemen ke HTTP 451 Tidak tersedia untuk status Alasan Hukum . Draf menyarankan bahwa respons 451 harus berisi geo-scope-blocktajuk yang harus "sesuai dengan daftar kode negara alfa-2 yang dipisahkan koma yang didefinisikan dalam [ISO.3166-1]". Namun, konsep tersebut juga menetapkan bahwa kode 451 tidak boleh digunakan "oleh operator untuk menolak akses ke sumber daya berdasarkan kebijakan yang ditentukan oleh operator (sebagai lawan dari tuntutan hukum yang ditempatkan pada operator)".

Jadi dengan asumsi Anda tidak memiliki permintaan hukum untuk geoblock, 451 bukan kode yang benar. Apa kode yang benar? Yah, banyak jawaban lain sudah menyarankan 403 Terlarang , tetapi semuanya tampaknya "berdasarkan pendapat", jadi mari kita lihat apa yang dilakukan orang lain:

Jadi, tidak ada satu solusi universal, Anda hanya harus memilih satu yang Anda rasa paling sesuai dengan situasi Anda. Namun, apa pun yang Anda pilih, pastikan untuk menjelaskan masalah aktual di badan respons .

Saya akan mengatakan tidak ada yang salah hanya dengan menentukan kode status HTTP khusus, seperti RubberDuck sudah menjawab . Kode status khusus dalam kisaran 400 mungkin sebenarnya adalah panggilan yang cukup bagus, karena itu pasti akan mendapatkan perhatian pengembang jika mereka melihat sesuatu seperti "HTTP status 499". "403" terlalu mudah untuk dilewati sebagai " OK jadi saya salah kata sandi, mari kita coba yang lain ", dan itu menghasilkan jam yang terbuang sia-sia.

Kosong satu
sumber