Quale dovrebbe essere il codice di stato http per l'errore "Servizio non disponibile nella tua zona"?

51

Il nostro servizio è in 5 città in questo momento. Se qualcuno prova a chiamare la nostra API di servizio da qualsiasi altra città, vogliamo lanciare questo errore Service not available in your area.

La domanda è: quale sarebbe il codice http appropriato per questo errore?

503 servizio non disponibile
403: proibito

o qualcos'altro?

api api-design http

— Shaharyar
fonte

52

"Se qualcuno tenta di chiamare la nostra API di servizio da qualsiasi altra città", nota che la geolocalizzazione IP è molto spesso sbagliata, se proibisci a qualsiasi utente la cui geolocalizzazione IP in un'altra città probabilmente stai bloccando gli utenti legittimi.

— Peter Green,

43

Non sono autorizzato a salutare un passaggio per mio figlio, che è in un'altra città e deve venire all'aeroporto per visitarmi?

— Dawood dice di ripristinare Monica il

29

Sebbene non sia una risposta alla domanda, HTTP 451 (RFC 7725) può essere utile per i futuri lettori che trovano questa domanda. Il suo scopo principale è quello di indicare che il contenuto non è disponibile a causa di una richiesta legale, azione o limitazione (copyright, ordinanza del tribunale, ecc.)

— Tyzoid,

34

Se non c'è nulla di sbagliato nella connettività di rete, nell'autenticazione, negli errori all'interno dell'applicazione e nell'input sintatticamente valido non dovrebbe esserci un messaggio di errore. Con "non offriamo il nostro servizio in quest'area" hai lasciato problemi tecnologici e hai affrontato problemi aziendali, quindi non sono sicuro che un errore HTTP sarebbe appropriato. Penso che dovresti dare un 200 e (o 302 e reindirizzare a) un messaggio appropriato su "mi dispiace che il nostro servizio non sia disponibile nella tua zona - ancora. Ma ci stiamo espandendo - Torna alla fine del 2019!" o qualunque sia il reparto marketing.

— Ivanivan,

7

Non è chiaro dalla domanda se intendi bloccare tutti gli accessi all'API in base alla posizione del computer client (geo IP?) O se stai chiedendo il codice di risposta per una particolare richiesta API non riuscita (ad esempio book? Address = 123_example_st_london) . La posizione fa parte dell'input o la posizione del cliente è in qualche altro modo?

— Ben

101

Qualsiasi codice di errore HTTP sarebbe inappropriato. Non ci sono errori o problemi di alcun tipo dal punto di vista HTTP, quindi dovrebbe essere qualcosa nell'intervallo 200. Informi cortesemente alcuni dei tuoi utenti che non saranno sottoposti a manutenzione inviando indietro un documento che glielo dice. E tutto va bene.

L'utente non sarà in grado di utilizzare l' applicazione . Questa è una decisione consapevole presa dalla tua logica aziendale, non un incidente. A livello HTTP è tutto onesto dory.

modificare

Sembra che quello che stiamo guardando qui sia uno scontro tra vecchia scuola e nuova scuola. Quando è stato progettato HTTP, non c'erano servizi web, né SOAP, né JSON, né principi REST. Come protocollo sopra TCP questo era già considerato (vicino) a livello di applicazione e sono stati definiti molti codici di stato di alto livello. Quando il web ha iniziato a essere utilizzato per servizi più ricchi e di alto livello e per la realizzazione di "buste" era necessario un mezzo comune, i progettisti preferivano HTTP anziché definire un protocollo più nuovo e più pulito, solo perché HTTP era onnipresente.

Quindi, in un moderno contesto di servizi Web, HTTP è effettivamente poco più di un livello di trasporto stupido e la maggior parte dei suoi codici può essere considerata non applicabile o obsoleta. Basta sceglierne uno perché si avvicina allo stato della tua applicazione e si trova in quell'elenco che una volta significava che qualcosa potrebbe sembrare innocuo, ma penso che invierebbe un messaggio sbagliato. Non si desidera che HTTP svolga quel ruolo di regolazione in un contesto di servizi Web.

— Martin Maat
fonte

56

In base a questa logica, qualsiasi errore dell'applicazione deve essere restituito come 200. E tutte le richieste devono essere POST, anche le eliminazioni. Questo approccio considera HTTP come un protocollo di trasporto opaco, come TCP. Questo non è il modo in cui le API dei servizi Web vengono generalmente trattate: provano a sfruttare la semantica HTTP come linguaggio standard per le API. Perché non restituire 401 per Non autorizzato, anziché restituire 200 con un codice di errore personalizzato e non standard?

— Avner Shahar-Kashtan,

31

Secondo questa logica, nessuna applicazione dovrebbe mai restituire una risposta nell'intervallo 400. Questo è esattamente il tipo di condizione per cui la gamma di risposte 400 è. Inoltre, la tua prima frase si applica a tutte le risposte future, nonché a quelle che sono state postate prima della tua?

— Dawood dice di ripristinare Monica il

31

Devo concordare qui che questo è solo un semplice 200. L'utente ha posto una domanda, l'abbiamo capita, conosciamo la risposta giusta e gli abbiamo fornito la risposta (che sembra essere "No"). Va tutto bene nella terra HTTP.

— Lee Daniel Crocker,

8

Hehe ... viaggio veloce da "questo non è davvero un errore" a "quindi, stai dicendo che niente è mai un errore?"

— svidgen,

28

Questo. "Hai tentato di accedere a un URL che non esiste" è molto diverso da "La nostra azienda non opera nella tua zona". Solo uno ha qualcosa a che fare con HTTP.

— CJ Dennis,

87

5xxgli errori sono errori del server - qualcosa è andato storto sul server. In particolare, un 503 indica che:

il server non è attualmente in grado di gestire la richiesta a causa di un sovraccarico temporaneo o della manutenzione programmata

4xxgli errori sono errori del client - il client sta facendo una richiesta che il server non è in grado o non è disposto a soddisfare. In particolare, un 403 indica che

il server ha compreso la richiesta ma si rifiuta di autorizzarla. Un server che desidera rendere pubblico il motivo per cui la richiesta è stata vietata può descrivere tale motivo nel payload di risposta (se presente). [..] Tuttavia, una richiesta potrebbe essere vietata per motivi non correlati alle credenziali.

Direi che 503è chiaramente errato, perché non si tratta di un problema temporaneo: non supportate le richieste in quell'area, punto. Si potrebbe argomentare che alla fine si spera di supportare l'area, ma l'intento del codice è di includere un'intestazione che indichi quando il client può riprovare. "In 6 mesi" non aderisce all'intento.

403 è una scelta migliore perché il tuo servizio proibisce semplicemente le richieste da determinate località.

— Eric Stein
fonte

403 è per i casi in cui l'accesso è vietato e il client non può farci nulla. Ma in questo caso il cliente può (salire in macchina con il proprio laptop o telefono), quindi 403 è inappropriato.

— gnasher729,

2

@ gnasher729 Gli errori 4xx riguardano cose che il client potrebbe essere in grado di risolvere, tra cui 403. Le specifiche (collegate) specificano che il client può riprovare con credenziali diverse (supponendo che le credenziali fossero il problema).

— jaxad0127,

22

@ gnasher729 403 non significa che l'essere umano non possa farci nulla. Significa che il browser non può farci nulla. L'essere umano può sempre eseguire una reimpostazione della password, parlare con l'amministratore o in questo caso spostarsi in un'altra città.

— Slebetman,

1

@ gnasher729 Il client non è l'utente.

— Captain Man,

10

5xx = Oops il nostro male, resisti mentre risolviamo il problema. 4xx = Siamo spiacenti ma al momento non siamo in grado di soddisfare la tua richiesta. Ecco perché ....

— candied_orange

46

Nessuno dei due.

Se la tua API è ben progettata, l'URL include il nome della città, ad es

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

o

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

poiché la geolocalizzazione IP non è affidabile, i tuoi utenti potrebbero utilizzare VPN, i tuoi utenti potrebbero desiderare un passaggio per qualcun altro, ecc. Suggerire una città in base alla posizione dell'utente è responsabilità del client API . Di solito, il client ha comunque risorse molto migliori per determinare la posizione dell'utente (ad esempio, il servizio di localizzazione di un dispositivo mobile).

Dopo averlo fatto, la risposta corretta a

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

o

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

diventa ovvio: 404 non trovato : non esiste alcuna risorsa per chiamare un passaggio su SomeUnsupportedCity.

— Heinzi
fonte

6

Questa dovrebbe essere la risposta accettata: il design dell'API non riguarda solo la conformità con i vecchi codici numerici e lo scenario su vpn's etc è piuttosto realistico.

— Edoardo,

10

Non sono d'accordo con questo. Includere il nome della città nell'URL potrebbe portare a tutti i tipi di problemi lungo la strada, perché costringe il cliente a determinare il nome di una città in base alla posizione e il risultato potrebbe non piacerti. Ad esempio, sei a Los Angeles o Beverly Hills? Londra o Westminster? Cosa succede se il cliente pensa che si trovi a Richardson, ma desideri che un'API serva l'intera area di Dallas? Sarebbe un'idea migliore per il cliente fornire solo le posizioni di ritiro / riconsegna; il server può determinare se si trovano nell'area di servizio e rispondere di conseguenza.

— Zach Lipton,

11

@ZachLipton Sono abbastanza sicuro che i nomi delle città fossero solo un esempio, dipende dalle effettive regole commerciali del PO come definiscono "città" o "località". Potrebbe anche essere una coordinata.

— Bergi,

1

@ZachLipton no, il punto qui non è che il servizio utilizzi l'IP client per capire la posizione, che è semplicemente sbagliato

— Edoardo,

3

@eddyce Sono d'accordo che l'utilizzo dell'IP client è una cattiva idea per molte ragioni. Sto dicendo che / API / Vienna / HailRide è anche soggetta a problemi, perché richiede al client di convertire le posizioni in nomi di città, e non si tratta di una mappatura 1 a 1 che corrisponde alle aree in cui un'azienda opera.

— Zach Lipton,

26

Sembra una domanda buco tondo / piolo quadrato. Perché la tua unica risposta deve essere un codice HTTP? I codici di errore HTTP non possono coprire tutti i casi d'uso.

Tutte le tue chiamate API dovrebbero avere messaggi aggiuntivi che ritornano, ad esempio un piccolo messaggio di errore JSON. Dai loro un 403 (perché, davvero, non hanno il permesso di usare l'API data la posizione) e restituisci un po 'di informazioni aggiuntive come stai suggerendo.

Se non lo fai, la prossima volta chiederai quale codice di errore HTTP restituire quando l'utente ha richiesto un SUV ma è disponibile solo una Prius.

— stdunbar
fonte

5

+1 per la tua ultima frase. Riassume bene.

— LoztInSpace,

1

Beh, sarebbe chiaramente necessario un reindirizzamento 3xx di qualche tipo. ;)

— Nome reale redatto il

L'ultimo caso probabilmente garantisce una risposta 4xx di qualche tipo: l'utente ha fatto una richiesta che il server non può soddisfare. Sarebbe 400 se la scelta fosse una sorta di input non valido o 404 se la posizione stessa non esistesse. Anche se potrebbe essere 200 se è un criterio di ricerca e non ci sono solo corrispondenze.

— jpmc26,

11

Alcuni hanno un senso.

403 Proibito, per i motivi che Eric Stein menziona nella sua risposta . È possibile utilizzare varie informazioni fornite dalla richiesta per determinare dove si trova il client e chi è il client e, in base a tale richiesta, il server non è in grado o non è disposto a rispondere.

Tuttavia, suggerirei 451 Non disponibile per motivi legali come possibile stato di restituzione in alcuni casi. Questo stato prevede di includere (nelle intestazioni) un collegamento alla legislazione pertinente. È specifico per i casi in cui non è legale per il cliente accedere alle proprie risorse e non esiste un caso più generale del client in un'area o un'area non supportata.

Eviterei la serie di stati 5xx - questi spesso indicano problemi tecnici sul lato server. Non sembra essere il caso qui.

— Thomas Owens
fonte

Probabilmente la ragione in questo caso è che non ha senso parlare all'utente di automobili che non si trovano nella loro città. Quindi non è il caso di 451

— max630,

4

@ max630 Non puoi supporre che dalla domanda. 403 Proibito è probabilmente la scelta giusta. Tuttavia, se ci sono restrizioni legali sul servizio, è possibile utilizzare il 451 più specifico. 451 è spesso vista come una versione più specifica di 403 per casi d'uso molto particolari, quindi ha senso parlarne.

— Thomas Owens

8

@ max630 - è del tutto possibile che 451 sia appropriato qui. Molte giurisdizioni richiedono che gli operatori di questo tipo di servizio siano registrati presso le autorità regionali prima di fornire il servizio. Potrebbero in realtà essere legalmente vietati dall'elaborazione di determinate richieste se provengono da un'area esterna.

— Jules,

5

Se la restrizione è dovuta a motivi legali, il codice di errore HTTP appropriato è HTTP 451, "Non disponibile per motivi legali".

Questo è in genere utilizzato nel caso di materiale che è stato revocato a causa di azioni DMCA o azioni legali a causa di campagne di molestie o simili, ma lo spirito e la lettera della definizione di risposta afferma:

Questo documento specifica un codice di stato HTTP (Hypertext Transfer Protocol) da utilizzare quando viene negato l'accesso alle risorse a seguito di richieste legali.

Il codice stesso è un riferimento a Fahrenheit 451 di Ray Bradbury.

— soffice
fonte

3

Le persone spesso dimenticano che i codici di stato HTTP sono estensibili.

I codici di stato HTTP sono estensibili. Le applicazioni HTTP non sono necessarie per comprendere il significato di tutti i codici di stato registrati, sebbene tale comprensione sia ovviamente desiderabile. Tuttavia, le applicazioni DEVONO comprendere la classe di qualsiasi codice di stato, come indicato dalla prima cifra, e trattare qualsiasi risposta non riconosciuta come equivalente al codice di stato x00 di quella classe, con l'eccezione che una risposta non riconosciuta NON DEVE essere memorizzata nella cache. Ad esempio, se il client riceve un codice di stato non riconosciuto di 431, può tranquillamente presumere che ci fosse qualcosa di sbagliato nella sua richiesta e trattare la risposta come se avesse ricevuto un codice di stato 400. In tali casi, gli agenti utente DOVREBBERO presentare all'utente l'entità restituita con la risposta,

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

È sempre possibile creare il proprio codice di stato nell'intervallo 400 per l'utilizzo da parte dell'API e dell'applicazione client.

— Papera di gomma
fonte

Hmm ... potrebbe non essere necessario se la richiesta includesse Expect token;city="Albequerque"un'intestazione. Quindi la risposta più appropriata sarebbe 417, aspettative fallite. tools.ietf.org/html/rfc2616#section-10.4.18 Supponendo ovviamente che questo sia per un servizio web.

— Berin Loritsch,

Forse non è necessario @BerinLoritsch, ma piuttosto che cercare di forzare l'inserimento di una situazione in un codice esistente, potrebbe essere meglio semplicemente puntare e usarne uno personalizzato.

— RubberDuck,

0

Inizialmente ho pensato al 503 perché la descrizione "servizio non disponibile" sembra allinearsi al problema, ma guardando le definizioni , il 503 è veramente specifico per la indisponibilità del server. Quindi, pensando di più, stai dicendo al client che c'è un problema con la richiesta, non che ci sia un problema sul lato server.

403 è più vicino perché stai dicendo all'utente che hai ricevuto il messaggio e lo capisci ma che il server non è disposto a soddisfarlo. Ciò potrebbe creare confusione, pertanto è possibile aggiungere una spiegazione testuale per descrivere lo scenario. Per RFC, 404 è anche un valido sostituto di questo codice.

A meno che qualcuno non abbia inventato un nuovo codice per questo, 403 o 404 sembrano essere i più vicini.

— JimmyJames
fonte

Sicuramente non un codice 5xx, perché ciò implica che provare la stessa richiesta in un secondo momento potrebbe avere successo. Un codice 4xx dice sicuramente al client di non riprovare senza modificare almeno parte della richiesta (in questo caso, il campo "posizione del servizio").

— Toby Speight,

0

Dovresti abbinare la descrizione dell'errore al codice che stai dando:

se lo dici Service not available in your area., dovresti dare un 404perché affermi che il servizio non è disponibile .
se lo dici You are not authorized for this service in your area.allora dovresti dare un 403perché affermi che il chiamante non è autorizzato .

Vorrei andare per il secondo.

— Edoardo
fonte

6

404 non riguarda la disponibilità , riguarda l' esistenza . Solo perché un servizio non è disponibile in alcune circostanze, non si dovrebbe fornire una risposta 404 a meno che non si desideri che le persone credano che non esista affatto. Una risposta 404 non avrebbe senso per questa situazione.

— Jules,

@jules Secondo le specifiche per 403 (che potrebbero non essere aggiornate): "Se il server non desidera rendere disponibili queste informazioni al client, al suo posto è possibile utilizzare il codice di stato 404 (Not Found) ". Quindi, se 403 è OK, anche 404 lo sarebbe, ma non necessariamente per il motivo indicato.

— JimmyJames,

@JimmyJames: sì, rientra nelle specifiche, ma è una pessima idea perché rende i problemi di debug estremamente difficili. Non quello che vuoi in un'API.

— Jules,

3

@Jules Il servizio non esiste in alcune aree. Proprio come ci sono molti piccoli negozi che esistono solo nella mia città, quindi chiedere al loro indirizzo in un'altra città la risposta corretta è "non esiste".

— Andy,

ehmm parlare di "esistenza" di un percorso di url di servizio è il meno - filosofico, per motivi di chiarezza una volta pubblicato un percorso devi fornire una risposta, 403 è la strada da percorrere in questo caso, con una sorta di descrizione verbale di la situazione.

— Edoardo,

0

Esiste un Internet Draft corrente (che scadrà il 31 dicembre 2018) che propone modifiche allo stato HTTP 451 non disponibile per motivi di motivi legali . La bozza suggerisce che una risposta 451 dovrebbe contenere geo-scope-blockun'intestazione che dovrebbe "corrispondere all'elenco separato da virgole dei codici paese alfa-2 definiti in [ISO.3166-1]". Tuttavia, il progetto specifica anche che il codice 451 non dovrebbe essere utilizzato "da un operatore per negare l'accesso a una risorsa sulla base di una politica specificata dall'operatore (al contrario di una domanda legale che viene posta sull'operatore)".

Quindi supponendo che tu non abbia una richiesta legale per il geoblock, 451 non è il codice corretto. Qual è il codice corretto allora? Bene, numerose altre risposte hanno già suggerito 403 Proibito , ma sembrano tutte "basate sull'opinione", quindi vediamo cosa stanno facendo gli altri:

Amazon CloudFront utilizza 403 Proibito
Twitter apparentemente restituisce 200 OK, ma spiega la questione nel contenuto JSON - ma questo è per singoli tweet, non per l'intera API
Pinterest utilizza 451
Il plug-in IP Geo Block di WordPress consente di scegliere qualsiasi codice esistente

Quindi, non esiste una soluzione universale, dovrai solo sceglierne una che ritieni più adatta alla tua situazione. Qualunque sia la tua scelta, assicurati di spiegare l'effettivo problema nel corpo della risposta .

Direi che non ci sarebbe nulla di male nel specificare un codice di stato HTTP personalizzato, come già risposto RubberDuck . Un codice di stato personalizzato nell'intervallo 400 potrebbe addirittura essere una buona chiamata, perché sicuramente attirerà l'attenzione degli sviluppatori se vedono qualcosa come "Stato HTTP 499". Un "403" è troppo facile da passare come " OK, quindi ho sbagliato la password, proviamo invece qualcos'altro ", e ciò si traduce in ore sprecate.

— Zero Uno
fonte