Qual deve ser o código de status http para o erro "Serviço indisponível em sua área"?

48

Nosso serviço está em 5 cidades agora. Se alguém tentar chamar nossa API de serviço de qualquer outra cidade, queremos lançar esse erro Service not available in your area .

A questão é, qual é o código http apropriado para este erro?

  • 503: serviço indisponível
  • 403: Proibido

ou algo mais?

    
por Shaharyar 12.07.2018 / 14:46
fonte

10 respostas

106

Qualquer código de erro HTTP seria inadequado. Não há nenhum erro ou problema de qualquer tipo a partir de uma perspectiva HTTP, então deve ser algo no intervalo de 200. Você educadamente informa alguns de seus usuários que eles não serão atendidos enviando de volta um documento que os informa. E tudo isso vai bem.

O usuário não poderá usar seu aplicativo . Essa é uma decisão consciente feita por sua lógica de negócios, não um contratempo. No nível do HTTP, tudo é honky.

Editar

Parece que o que estamos vendo aqui é um choque entre a velha escola e a nova escola. Quando o HTTP foi projetado, não havia serviços da Web, não havia SOAP, sem JSON, sem princípios REST. Como um protocolo acima do TCP, isso já era considerado (próximo a) nível de aplicação e muitos códigos de status de alto nível foram definidos. Quando a web começou a ser usada para serviços mais sofisticados e de alto nível, era necessário um meio comum para transportar "envelopes", projetando HTTP de alta tecnologia em vez de definir um protocolo mais novo e mais limpo, só porque o HTTP era onipresente.

Assim, em um contexto de serviço da Web moderno, o HTTP é, na verdade, pouco mais que uma camada de transporte burra e a maioria de seus códigos pode ser considerada não aplicável ou obsoleta. Basta escolher um, porque ele se aproxima do estado do seu aplicativo e, por acaso, está na lista que uma vez significou que algo pode parecer inofensivo, mas acho que ele enviaria uma mensagem errada. Você não quer que o HTTP desempenhe essa função reguladora em um contexto de serviço da Web.

    
por 12.07.2018 / 19:54
fonte
82

5xx erros são erros do servidor - algo deu errado no servidor. Em particular, um 503 indica que:

the server is currently unable to handle the request due to a temporary overload or scheduled maintenance

4xx erros são erros do cliente - o cliente está fazendo uma solicitação que o servidor não pode ou não deseja cumprir. Em particular, um 403 indica que

the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any). [..] However, a request might be forbidden for reasons unrelated to the credentials.

Eu diria que 503 está claramente incorreto, porque isso não é um problema temporário - você não suporta solicitações nessa área, ponto final. Pode-se argumentar que você eventualmente deseja suportar a área, mas a intenção do código é incluir um cabeçalho indicando quando o cliente pode tentar novamente. "Em 6 meses" não adere à intenção.

403 é a melhor opção porque seu serviço simplesmente proíbe solicitações de determinados locais.

    
por 12.07.2018 / 15:27
fonte
44

Nenhum desses.

Se sua API for bem projetada, o URL incluirá o nome da cidade, por exemplo,

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

ou

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

como a geolocalização por IP não é confiável, seus usuários podem estar usando VPNs, seus usuários podem querer chamar a atenção de outra pessoa, etc. Sugerir uma cidade com base na localização do usuário é o cliente da API . responsabilidade. Geralmente, o cliente tem recursos muito melhores para determinar a localização do usuário de qualquer maneira (por exemplo, o serviço de localização de um dispositivo móvel).

Depois de fazer isso, a resposta correta para

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

ou

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

torna-se óbvio: 404 Not Found : não existe recurso para chamar um passeio em SomeUnsupportedCity.

    
por 12.07.2018 / 22:11
fonte
26

Isto parece uma questão de buraco redondo / quadrado. Por que sua única resposta precisa ser um código HTTP? Os códigos de erro HTTP não podem abranger todos os casos de uso.

Todas as suas chamadas de API devem ter mensagens adicionais que retornem, ou seja, uma pequena mensagem de erro JSON. Dê a eles um 403 (porque, na verdade, eles não têm permissão para usar a API de acordo com o local) e retornem um pouco mais de informações conforme você sugere.

Se você não fizer isso, na próxima vez, você perguntará qual código de erro HTTP deve ser retornado quando o usuário solicitar um SUV, mas apenas um Prius estará disponível.

    
por 12.07.2018 / 18:40
fonte
11

Alguns fazem sentido.

403 Proibido, pelas razões que Eric Stein menciona em sua resposta . Você pode usar várias informações fornecidas pela solicitação para determinar onde o cliente está e quem é o cliente e, com base nessa solicitação, o servidor não pode ou não deseja responder.

No entanto, eu também colocaria 451 Unavailable for Legal Reasons como um possível status de retorno para alguns casos. Esse status espera que você inclua (nos cabeçalhos) um link para a legislação relevante. É especificamente para casos em que não é legal o cliente acessar seus recursos, e não existe um caso mais geral do cliente em uma região ou área não suportada.

Eu evitaria a série de status 5xx - isso geralmente indica problemas técnicos do lado do servidor. Não parece ser o caso aqui.

    
por 12.07.2018 / 15:36
fonte
5

Se a restrição for devida a motivos legais, o código de erro HTTP apropriado é HTTP 451, "Indisponível por motivos legais".

Normalmente, isso é usado no caso de material que foi revogado devido a ações ou ações judiciais da DMCA devido a campanhas de assédio ou afins, mas o espírito e letra da definição de resposta afirma:

This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.

O próprio código é uma referência a Fahrenheit 451 de Ray Bradbury.

    
por 13.07.2018 / 02:50
fonte
3

As pessoas geralmente esquecem que os códigos de status HTTP são extensíveis.

HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human- readable information which will explain the unusual status.

link

Você sempre pode criar seu próprio código de status no intervalo 400 para ser usado pela sua API e aplicativo cliente.

    
por 15.07.2018 / 14:36
fonte
1

403 é o código, mas você deve corresponder à descrição do erro com o código que você está dando: se você diz

Service not available in your area.

você deve dar um 404 porque afirma que o serviço não está disponível . se você disser

You are not authorized for this service in your area.

então você deve dar um 403 porque você afirma que o chamador não está autorizado . Eu iria pelo segundo.

    
por 12.07.2018 / 16:09
fonte
0

No começo eu pensei em 503 porque a descrição "serviço indisponível" parece se alinhar com o problema, mas olhando para o definições , 503 é realmente específico para a indisponibilidade do servidor. Então, pensando mais, você está dizendo ao cliente que há um problema com a solicitação, não que exista um problema no servidor.

403 está mais próximo porque você está dizendo ao usuário que recebeu a mensagem e a entendeu, mas que o servidor não está disposto a satisfazê-la. Isso pode ser confuso, portanto, uma explicação textual pode ser adicionada para descrever o cenário. De acordo com o RFC, o 404 também é um substituto válido para esse código.

A menos que alguém tenha sonhado com um novo código para isso, 403 ou 404 parecem ser os mais próximos.

    
por 12.07.2018 / 15:30
fonte
0

Há um projeto da Internet atual (que expirará em 31 de dezembro de 2018) que propõe alterações ao status HTTP 451 Indisponível por motivos legais . O rascunho sugere que uma resposta 451 deve conter um cabeçalho geo-scope-block que deve "corresponder à lista separada por vírgula dos códigos de país alfa-2 definidos em [ISO.3166-1]". No entanto, o esboço também especifica que o código 451 não deve ser usado "por um operador para negar acesso a um recurso com base em uma política especificada pelo operador (em oposição a uma demanda legal imposta ao operador)". / p>

Portanto, supondo que você não tenha uma demanda legal para o geoblock, o 451 não é o código correto. Qual é o código correto então? Bem, várias outras respostas já sugeriram 403 Forbidden , mas todas parecem ser "baseadas em opiniões", então vamos ver o que os outros estão fazendo:

Então, não há uma solução universal, você vai ter que escolher uma que melhor se adapte à sua situação. Mas, seja qual for a sua escolha, certifique-se de explicar o problema real no corpo da resposta .

Eu diria que não haveria nada de errado em apenas especificar um código de status HTTP personalizado, como RubberDuck já respondeu . Um código de status personalizado na faixa de 400 pode até mesmo ser uma boa opção, porque isso definitivamente chamará a atenção dos desenvolvedores se virem algo como "status HTTP 499". Um "403" é muito fácil de passar como " OK, então eu tenho minha senha errada, vamos tentar outra coisa ", e isso resulta em horas desperdiçadas.

    
por 16.07.2018 / 15:52
fonte