“Bölgenizde bulunmayan servis” hatası için http durum kodu ne olmalıdır?

51

Hizmetimiz şu anda 5 ilde. Birisi hizmet API’nizi başka bir şehirden aramaya çalışırsa, bu hatayı atmak istiyoruz Service not available in your area.

Sorun şu ki, bu http için uygun http kodu ne olurdu?

503 Hizmet Kullanılamıyor
403 yasak

veya başka bir şey?

api api-design http

— Shaharyar
kaynak

52

"Birisi hizmet API’nizi başka bir şehirden aramaya çalışırsa" IP coğrafi konumlandırmasının çok yanlış olduğunu unutmayın; IP’yi başka bir şehre konumlandıran herhangi bir kullanıcıyı yasakladığınız takdirde, meşru kullanıcıları kapatırsınız.

— Peter Green,

43

Başka bir şehirde olan ve beni ziyaret etmek için havaalanına gelmesi gereken çocuğum için bir gezintiye çıkmam yasak mı?

— Dawood ibn Kareem

29

Sorunun cevabı olmasa da, HTTP 451 (RFC 7725) bu soruyu bulan gelecekteki okuyucular için faydalı olabilir. Asıl amacı, içeriğin yasal bir istek, işlem veya kısıtlama nedeniyle (telif hakkı, mahkeme emri vb.) Uygun olmadığını göstermektir

— Tyzoid

34

Ağ bağlantısı, kimlik doğrulama, uygulamada dahili olarak hata yok ve sözdizimsel olarak geçerli olan girişlerde yanlış bir şey yoksa, bir hata mesajı olmamalıdır. "Bu alanda hizmetimizi sunmuyoruz" seçeneğiyle, teknoloji sorunlarını bıraktınız ve işletme sorunlarına girdiniz, bu nedenle bir HTTP hatasının uygun olacağından emin değilim. Bence 200 ve (veya 302 ve yönlendirmeye) uygun bir mesaj göndermelisiniz "üzgünüm, hizmetiniz henüz bölgenizde mevcut değil - ama genişliyoruz - 2019’un sonlarında tekrar kontrol edin!" ya da pazarlama borcu ne olursa olsun.

— ivanivan

7

İstemci bilgisayarın konumuna göre (coğrafi IP?) API’ye tüm erişimi engellemek mi, yoksa belirli bir başarısız API isteği için cevap kodunu mu sormak istediğinizi (örneğin kitap? Adres = 123_example_st_london) sorusu açık değil. . Konum girişin bir parçası mı yoksa müşterinin yerini başka bir şekilde mi alıyorsunuz?

— Ben,

102

Herhangi bir HTTP hata kodu uygun olmaz. HTTP perspektifinden herhangi bir hata veya sorun yoktur, bu yüzden 200 aralığında bir şey olmalıdır. Bazı kullanıcılarınıza kibarca, onlara söyleyen bir belgeyi geri göndererek hizmet verilmeyeceğini bildirirsiniz. Ve bunların hepsi iyi gidiyor.

Kullanıcı başvurunuzu kullanamaz . İş mantığınız tarafından verilen bilinçli bir karardır, bir aksilik değil. HTTP seviyesinde her şey honky dory.

Düzenle

Burada aradığımız şey eski okuldan yeni okula karşı bir çatışma gibi gözüküyor. HTTP tasarlandığında web hizmetleri yoktu, SOAP, JSON, REST ilkeleri yoktu. TCP'nin üstündeki bir protokol olarak, bu zaten uygulama seviyesine (yakın) kabul edildi ve birçok yüksek seviye durum kodu tanımlandı. Web daha zengin, yüksek seviyeli servisler için kullanılmaya başladığında ve "zarfları" taşımak için ortak bir araç gerekliyse, tasarımcıların daha yeni ve daha temiz bir protokol tanımlamak yerine, HTTP'nin her zaman olduğu gibi tasarımcılar hi-jacked HTTP kullandılar.

Dolayısıyla, modern bir web servis bağlamında, HTTP gerçekten aptal bir taşıma katmanından biraz daha fazladır ve kodlarının çoğunun uygulanabilir veya eski olduğu düşünülebilir. Sadece bir tane seçmeniz yeterlidir, çünkü bu sizin uygulama durumunuza yaklaşır ve bir zamanlar zararsız görünebileceği anlamına gelen listede yer alır. HTTP'nin bu düzenleyici rolü bir web hizmeti bağlamında oynamasını istemiyorsunuz.

— Martin Maat
kaynak

56

Bu mantıkla, herhangi bir uygulama hatası 200 olarak döndürülmelidir. Ve tüm istekler POST, hatta silme olmalıdır. Bu yaklaşım, HTTP'yi bir opak taşıma protokolü - TCP gibi görür. Bu, web hizmeti API'lerine genellikle nasıl davranıldığından ibaret değildir - HTTP semantiğinden, API'ler için standart bir dilden yararlanmaya çalışırlar. Neden özel, standart olmayan bir hata koduyla 200'ü döndürmek yerine, Yetkisiz için 401'i geri döndürmüyorsunuz?

— Avner Shahar-Kashtan

31

Bu mantıkla, hiçbir uygulama 400 aralığında hiçbir yanıt vermemelidir. Bu, tam olarak 400 yanıt yelpazesinin öngördüğü koşul türüdür. Ayrıca, ilk cümleniz gelecekteki tüm cevaplar için ve sizinkinden önce gönderilenler için de geçerli midir?

— Dawood ibn Kareem

31

Burada bunun sadece düz bir 200 olduğu konusunda hemfikir olmalıyım. Kullanıcı bir soru sordu, anladık, doğru cevabı biliyoruz ve ona cevabı verdik ("Hayır" olur). HTTP ülkesinde her şey yolunda.

— Lee Daniel Crocker

8

Hehe ... "Bu gerçekten bir hata değil" den "hızlı yolculuk, yani hiçbir şeyin bir hata olmadığını mı söylüyorsun?"

— svidgen

28

Bu. "Var olmayan bir URL’ye erişmeye çalıştınız", "Şirketimiz sizin bölgenizde çalışmaz" dan çok farklı. Sadece birinin HTTP ile ilgisi var.

— CJ Dennis

87

5xxhatalar sunucu hataları - sunucuda bir şeyler ters gitti. Özellikle, bir 503 şunları belirtir:

Sunucu şu anda geçici bir aşırı yüklenme veya zamanlanmış bakım nedeniyle isteği yerine getiremiyor

4xxhatalar istemci hatalarıdır - istemci sunucunun gerçekleştirememesi veya yerine getirmeyi istememesi talebinde bulunur. Özel olarak, bir 403 belirtir

sunucu isteği anladı ancak izin vermeyi reddetti. İsteğin neden yasaklandığını kamuoyuna açıklamak isteyen bir sunucu yanıt yükünde (varsa) bu nedeni açıklayabilir. [..] Bununla birlikte, kimlik bilgileriyle ilgisi olmayan nedenlerle bir talep yasaklanabilir.

Bunun 503açıkça yanlış olduğunu iddia ediyorum , çünkü bu geçici bir mesele değil - o bölgedeki talepleri desteklemiyorsunuz. Sonunda alanı desteklemeyi umduğunuzu iddia edebiliriz, ancak kodun amacı müşterinin tekrar ne zaman deneyebileceğini belirten bir başlık içermektir. "6 ayda" amacına uygun değil.

403 daha iyi bir seçimdir, çünkü hizmetiniz belirli bölgelerden gelen talepleri yasaklar.

— Eric Stein
kaynak

403, erişimin yasak olduğu durumlar içindir ve müşteri bu konuda hiçbir şey yapamaz. Ancak bu durumda müşteri (dizüstü bilgisayarınız veya telefonunuzla arabaya binebilirsiniz), bu nedenle 403 uygunsuz.

— gnasher729

2

@ gnasher729 4xx hataları, 403 da dahil olmak üzere müşterinin çözebileceği şeyler içindir. (bağlantılı) şartı özellikle müşterinin farklı kimlik bilgileriyle yeniden deneyebileceğini belirtir (kimlik bilgilerinin sorun olduğunu varsayarak).

— jaxad0127

22

@ gnasher729 403, insanın hiçbir şey yapamayacağı anlamına gelmez. Tarayıcının bu konuda hiçbir şey yapamayacağı anlamına gelir. İnsan her zaman bir şifre sıfırlama yapabilir, yönetici ile konuşabilir veya bu durumda başka bir şehre taşınır.

— slebetman

1

@ gnasher729 İstemci kullanıcı değil.

— Kaptan Adam,

10

5xx = Hatamızı kapattık, sorunu çözerken telefonu kapat. 4xx = Üzgünüz, ancak politika gereği isteğinizi şu anda yerine getiremiyoruz. İşte nedeni ....

— candied_orange

46

Bunların hiçbiri.

API’niz iyi tasarlanmışsa, URL, şehrin adını içerir;

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

veya

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

IP konum belirleme özelliği güvenilir olmadığından, kullanıcılarınız VPN kullanıyor olabilir, kullanıcılarınız başkaları için bir gezintiye çıkmak isteyebilir, vb. Kullanıcının bulunduğu yere göre bir şehir önermek API müşterisinin sorumluluğundadır. Genellikle, müşteri yine de kullanıcının yerini belirlemek için çok daha iyi kaynaklara sahiptir (örneğin, bir mobil cihazın konum servisi).

Bunu yaptıktan sonra, doğru cevap

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

veya

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

aşikar hale gelir: 404 Bulunamadı : SomeUnsupportedCity'de gezintiye çıkmak için bir kaynak yok.

— Heinzi
kaynak

6

Bu kabul edilen cevap olmalıdır: API tasarımı sadece eski sayısal kodlara uymakla ilgili değildir ve vpn'nin vb. Senaryosu oldukça gerçekçidir.

— Edoardo

10

Buna katılmıyorum. URL’ye şehir adını dahil etmek yolun aşağısında her türlü soruna yol açabilir, çünkü müşteriyi yere göre bir şehir adı belirlemeye zorlar ve sonucu beğenmeyebilirsiniz. Mesela Los Angeles'ta mı yoksa Beverly Hills'de misiniz? Londra ya da Westminster? Müşteri, Richardson’da olduğunu düşünüyorsa, ancak tüm Dallas alanına hizmet verecek bir API’yi ister misiniz? Müşterinin sadece alım / bırakma lokasyonlarını tedarik etmesi daha iyi bir fikir olacaktır; Sunucu, servis alanında olup olmadıklarını belirleyebilir ve buna göre yanıt verebilir.

— Zach Lipton,

11

@ZachLipton Şehir adlarının sadece bir örnek olduğuna emindim, OP'nin gerçek işletme kurallarına "şehir" veya "konum" u nasıl tanımladıklarına bağlı. Bir koordinat olabilir.

— Bergi

1

@ZachLipton hayır, buradaki nokta, hizmeti anlamak için istemci IP'sini kullanmak değil, sadece yanlıştır

— Edoardo

3

@ eddyce IP istemcisini kullanmanın birçok nedenden dolayı kötü bir fikir olduğuna katılıyorum. / API / Vienna / HailRide'ın da sorunlara açık olduğunu söylüyorum çünkü müşterinin yerleri şehir isimlerine dönüştürmesini gerektiriyor ve bu bir şirketin iş yaptığı alanlara karşılık gelen bire bir eşleme değil.

— Zach Lipton,

26

Bu yuvarlak bir delik / kare peg sorusu gibi görünüyor. Tek cevabınız neden bir HTTP kodu olmak zorunda? HTTP hata kodları muhtemelen tüm kullanım durumlarını kapsayamaz.

Tüm API çağrılarınız geri gelen ek mesajlara sahip olmalıdır - yani küçük bir JSON hata mesajı. Onlara bir 403 verin (çünkü, konum olarak verilen API'yi kullanma iznine sahip değiller) ve önerdiğiniz gibi bir miktar bilgi geri gönderin.

Bunu yapmazsanız, bir dahaki sefere, kullanıcı bir SUV istediğinde ancak yalnızca bir Prius kullanılabilir olduğunda hangi HTTP hata kodunun döneceğini soracaksınız.

— stdunbar
kaynak

5

Son cümleniz için +1. Güzelce özetler.

— LoztInSpace

1

Bu oldukça net bir şekilde bir tür 3xx yönlendirmesi olması gerekirdi. ;)

— Brandon

Son dava muhtemelen bir tür 4xx yanıtı garanti eder: kullanıcı, sunucunun yerine getiremeyeceği bir istek yaptı. Seçim bir çeşit geçersiz girdi ise 400, yerin kendisi mevcut değilse 404 olur. Her ne kadar bir arama kriteri ise 200 olabilir ve sadece eşleşme olmaz.

— jpmc26

11

Birkaç mantıklı.

403 Yasak, Eric Stein'in cevabında bahsettiği nedenlerden dolayı . İstemcinin nerede olduğunu ve müşterinin kim olduğunu belirlemek için istek tarafından sağlanan çeşitli bilgileri ve bu talebe bağlı olarak, sunucunun yanıt verememesi veya isteksiz olması durumunda kullanabilirsiniz.

Bununla birlikte, bazı davalarda olası bir iade durumu olarak 451 Yasal Sebep Kullanılamıyor olduğunu da ileri süreceğim. Bu statü (başlıklarda) ilgili mevzuata bir bağlantı eklemenizi bekler. Özellikle, müşterinin kaynaklarınıza erişmesinin yasal olmadığı ve müşterinin daha genel bir durumu desteklenmeyen bir bölgede veya alanda mevcut olmadığı durumlar için geçerlidir.

5xx serisi durumlardan kaçınırdım - bunlar genellikle sunucu tarafında teknik sorunları gösterir. Burada durum böyle görünmüyor.

— Thomas Owens
kaynak

Muhtemelen bu durumda sebebi, kullanıcılarına şehirlerinde olmayan araçlar hakkında söylemenin bir anlamı yoktur. Öyleyse 451

— max630

4

@ max630 Bunu sorudan kabul edemezsiniz. 403 Yasak büyük olasılıkla doğru seçimdir. Ancak, hizmetle ilgili yasal kısıtlamalar varsa, bunun yerine daha spesifik 451 kullanılabilir. 451, çok özel kullanım durumları için genellikle 403'ün daha spesifik bir versiyonu olarak görülür, bu nedenle bunu ortaya çıkarmak mantıklıdır.

— Thomas Owens

8

@ max630 - burada 451'in uygun olması tamamen mümkündür. Pek çok yargı alanı, bu tür bir hizmet işletmecisinin, hizmeti sunmadan önce bölgesel otoritelere kayıt yaptırmasını gerektirir. Alan dışından geliyorsa, belirli talepleri yerine getirmeleri yasal olarak yasaklanmış olabilir.

— Jules

5

Kısıtlama yasal nedenlerden kaynaklanıyorsa, uygun HTTP hata kodu HTTP 451'dir, "Yasal nedenlerden dolayı kullanılamaz."

Bu, genellikle DMCA eylemi nedeniyle iptal edilen materyal veya taciz kampanyaları veya benzerleri nedeniyle açılan davalar için kullanılır, ancak yanıt tanımının özü ve mektubu şöyledir:

Bu belge, yasal taleplerin bir sonucu olarak kaynak erişiminin reddedilmesi durumunda kullanılacak bir Köprü Metni Aktarım Protokolü (HTTP) durum kodunu belirtir.

Kod, Ray Bradbury'nin Fahrenheit 451'e referansıdır .

— kabarık
kaynak

3

İnsanlar genellikle HTTP durum kodlarının genişletilebilir olduğunu unuturlar.

HTTP durum kodları genişletilebilir. HTTP uygulamaları, tüm kayıtlı durum kodlarının anlamını anlamak için zorunlu değildir, ancak bu tür bir anlayış açıkça istenmektedir. Ancak, başvurular, ilk basamakta belirtildiği gibi herhangi bir durum kodunun sınıfını anlamalıdır ve tanınmayan bir yanıtın, tanınmayan bir yanıtın önlenmemesi haricinde, o sınıfın x00 durum koduna eşdeğer olduğu kabul edilir. Örneğin, müşteri tarafından 431 tanınmayan bir durum kodu alınırsa, isteğinde bir sorun olduğunu kabul edebilir ve yanıtı 400 durum kodu almış gibi ele alabilir. Bu gibi durumlarda, kullanıcı aracıları, kullanıcıya yanıtla iade edilen işletmeyi sunmak zorundadır.

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

API ve istemci uygulamanızın kullanımı için her zaman yalnızca 400 aralığında kendi durum kodunuzu oluşturabilirsiniz .

— Plastik ördek
kaynak

Hmm ... istek bir Expect token;city="Albequerque"başlık içeriyorsa gerekli olmayabilir . Daha sonra en uygun cevap 417 olacaktır, beklenti başarısız olmuştur. tools.ietf.org/html/rfc2616#section-10.4.18 Elbette bunun bir web servisi için olduğunu varsaymak .

— Berin Loritsch

Belki gerekli değildir @BerinLoritsch, ancak bir durumu varolan bir koda uydurmaya zorlamak yerine, sadece özel bir tane seçip kullanmak daha iyi olabilir .

— RubberDuck

0

İlk başta 503 demiştim, çünkü "hizmet kullanılamıyor" tanımı sorunla aynı hizada görünüyor, ancak tanımlara bakarak , 503 sunucu kullanılamamasına gerçekten özgü. Daha sonra daha fazla düşünerek, müşteriye bir sunucu tarafı sorunu olmadığını, istekle ilgili bir sorun olduğunu söylüyorsunuz.

403 daha yakındır, çünkü kullanıcıya mesajı aldığını ve onu anladığını ancak sunucunun onu tatmin etmek istemediğini söylediğini söylüyorsun. Bu kafa karıştırıcı olabilir, bu nedenle senaryoyu açıklamak için metinsel bir açıklama eklenebilir. RFC'ye göre, 404 bu kod için geçerli bir alternatiftir.

Birisi bunun için yeni bir kod hayal etmediyse, 403 veya 404 en yakın görünüyor.

— JimmyJames
kaynak

Kesinlikle bir 5xx kodu değil, çünkü daha sonra aynı isteği denemenin başarılı olabileceği anlamına gelir. 4xx kodu kesinlikle müşteriye isteğin en azından bir kısmını değiştirmeden tekrar denememesini söyler (bu durumda, "servis konumu" alanı).

— Toby Speight

0

Hatanın açıklamasını, verdiğiniz kodla eşleştirmelisiniz:

derseniz Service not available in your area.o zaman bir vermelidir 404hizmet olmadığını iddia ettikleri için kullanılabilir .
eğer söylerseniz , arayanın yetkili olmadığını iddia ettiğiniz için You are not authorized for this service in your area.bir karar vermelisiniz .403

İkincisi için giderdim.

— Edoardo
kaynak

6

404 mevcudiyetle ilgili değil , varoluşla ilgili . Sırf bir hizmetin bazı durumlarda kullanılamaması nedeniyle, insanların hiçbir şeyin olmadığına inanmasını istemediğiniz sürece 404 yanıtı vermemelisiniz. Bir 404 yanıtı bu durum için anlamsız olacaktır.

— Jules

jules 403 spesifikasyonuna göre (güncel olmayan olabilir): "Sunucu bu bilgiyi müşteriye sunmak istemezse, bunun yerine 404 durum kodu (Bulunamadı) kullanılabilir. " Öyleyse, 403 tamam ise, o zaman 404 de olabilirdi, ancak verilen nedenden dolayı mutlaka değil.

— JimmyJames

@JimmyJames - evet, şartname dahilinde, ancak hata ayıklama sorunlarını son derece zorlaştırdığı için gerçekten kötü bir fikir . Bir API'de istediğinizi değil.

— Jules

3

Gelmez hizmeti @Jules mevcut bazı alanlarda. Benim şehrimde var olan birçok küçük mağaza gibi, bu yüzden adreslerini başka bir şehirde sormak doğru cevap "yok".

— Andy,

ehmm bir hizmet url yolu hakkında "var olma" hakkında konuşmak en az - felsefidir, netlik açısından bir yol yayınladığınızda bir cevap vermeniz gerekir, 403 bu durumda, bir tür sözlü betimlemeyle durum.

— Edoardo,

0

Bir var şimdiki Internet Taslak değişiklik önerdi (yani 31 Aralık 2018 tarihinde sona erecektir) Yasal nedenler için kullanılamaz HTTP 451 durumu. Taslak, bir 451 cevabının geo-scope-block"[ISO.3166-1] 'de tanımlanan virgülle ayrılmış alfa-2 ülke kodları listesine karşılık gelmesi gereken" bir başlık içermesi gerektiğini öne sürüyor . Bununla birlikte, taslak ayrıca, 451 kodunun "operatör tarafından belirlenen bir politikaya dayanarak (operatöre konan yasal bir talebin aksine) bir kaynağa erişimi reddetmek için bir operatör tarafından" kullanılması gerektiğini belirtir.

Jeoblok için yasal bir talebiniz olmadığını varsayarsak, 451 doğru kod değildir. Doğru kod nedir o zaman? Pek çok başka cevaplar zaten 403 Yasak önerdi , ancak hepsi "görüşe dayalı" gibi görünüyor, o yüzden başkalarının ne yaptığını görelim:

Amazon CloudFront, 403 Yasaklı kullanır
Twitter görünüşte 200 OK döndürüyor ancak JSON içeriğindeki konuyu açıklıyor - ancak API için değil, tweet'lerin tümü için
Pinterest 451 kullanıyor
WordPress IP Geo Block eklentisi varolan herhangi bir kodu seçmenize olanak sağlar

Yani, tek bir evrensel çözüm yok, sadece durumunuza en uygun olduğunu düşündüğünüz birini seçmek zorunda kalacaksınız. Ancak hangisini seçerseniz seçin, yanıt gövdesindeki asıl konuyu açıkladığınızdan emin olun .

RubberDuck'ın zaten cevapladığı gibi, sadece özel bir HTTP durum kodu belirlemede yanlış bir şey olmadığını söyleyebilirim . 400 aralığındaki özel bir durum kodu aslında oldukça iyi bir çağrı olabilir, çünkü "HTTP status 499" gibi bir şey görürlerse geliştiricilerin dikkatini çekecektir. Bir "403" " Tamam, bu yüzden şifremi yanlış anladım, onun yerine başka bir şey deneyelim " olarak geçilmesi çok kolay ve bu da boşa harcanan saatlerle sonuçlanıyor.

— Sıfır bir
kaynak