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

Nosso serviço está em 5 cidades no momento. 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 seria o código http apropriado para esse erro?

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

ou alguma outra coisa?

Qualquer código de erro HTTP seria inapropriado. Não há nenhum erro ou problema de qualquer tipo na perspectiva HTTP, portanto deve ser algo no intervalo 200. Você informa educadamente 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 tomada pela lógica de negócios, não um acidente. No nível HTTP, tudo é honky dory.

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 princípios SOAP, JSON ou REST. Como um protocolo acima do TCP, isso já era considerado (próximo) ao nível do aplicativo 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 e um meio comum de transportar "envelopes" era necessária, os designers fizeram o upload do HTTP, em vez de definir um protocolo mais novo e limpo, apenas porque o HTTP era onipresente.

Portanto, em um contexto moderno de serviço da web, o HTTP é realmente pouco mais que uma camada de transporte idiota 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 aplicativo e está nessa lista que antes significava que algo pode parecer inofensivo, mas acho que enviaria uma mensagem errada. Você não deseja que o HTTP desempenhe essa função reguladora em um contexto de serviço da web.

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

atualmente, o servidor não consegue lidar com a solicitação devido a uma sobrecarga temporária ou manutenção agendada

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

o servidor entendeu a solicitação, mas se recusa a autorizá-la. Um servidor que deseja tornar público o motivo pelo qual a solicitação foi proibida pode descrever esse motivo na carga útil da resposta (se houver). [..] No entanto, uma solicitação pode ser proibida por razões não relacionadas às credenciais.

Eu argumentaria que isso 503é claramente incorreto, porque esse não é um problema temporário - você não suporta solicitações nessa área, ponto final. Pode-se argumentar que você espera apoiar 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 é uma escolha melhor porque seu serviço proíbe simplesmente solicitações de determinados locais.

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 de IP não é confiável, seus usuários podem estar usando VPNs, eles podem desejar uma carona para outra pessoa etc. Sugerir uma cidade com base na localização do usuário é de responsabilidade do cliente da API . 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 Não encontrado : não existe recurso para chamar uma carona em SomeUnsupportedCity.

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

Todas as suas chamadas de API devem ter mensagens adicionais que retornam - ou seja, uma pequena mensagem de erro JSON. Dê a eles um 403 (porque, realmente, eles não têm permissão para usar a API, dada a localização) e retorne um pouco de informação adicional, conforme sugerido.

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

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 quer responder.

No entanto, eu também apresentaria 451 Indisponível por motivos legais 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 para 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 5xx de status - isso geralmente indica problemas técnicos no servidor. Não parece ser o caso aqui.

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

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

Este documento especifica um código de status HTTP (Hypertext Transfer Protocol) para uso quando o acesso a recursos é negado como consequência de demandas legais.

O código em si é uma referência ao Fahrenheit 451 de Ray Bradbury.

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

Os códigos de status HTTP são extensíveis. Os aplicativos HTTP não são necessários para entender o significado de todos os códigos de status registrados, embora esse entendimento seja obviamente desejável. No entanto, os aplicativos DEVEM entender a classe de qualquer código de status, conforme indicado pelo primeiro dígito, e tratar qualquer resposta não reconhecida como equivalente ao código de status x00 dessa classe, com a exceção de que uma resposta não reconhecida NÃO DEVE ser armazenada em cache. Por exemplo, se um código de status não reconhecido de 431 for recebido pelo cliente, ele poderá assumir com segurança que havia algo errado com sua solicitação e tratar a resposta como se tivesse recebido um código de status 400. Nesses casos, os agentes de usuário DEVEM apresentar ao usuário a entidade retornada com a resposta,

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

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

No começo, pensei 503 porque a descrição "serviço indisponível" parece estar alinhada com o problema, mas olhando as definições , 503 é realmente específico da indisponibilidade do servidor. Depois, pensando mais, você está dizendo ao cliente que há um problema com a solicitação, não que haja um problema no lado do servidor.

403 está mais perto porque você está dizendo ao usuário que recebeu a mensagem e a entende, mas que o servidor não está disposto a satisfazê-la. Isso pode ser confuso para que uma explicação textual possa ser adicionada para descrever o cenário. Pela RFC, 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.

Você deve corresponder a descrição do erro ao código que está fornecendo:

• se você diz Service not available in your area., deve dar um 404porque afirma que o serviço não está disponível .

• se você diz You are not authorized for this service in your area., deve dar um 403porque afirma que o chamador não está autorizado .

Eu iria pelo segundo.

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

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

• O Amazon CloudFront usa 403 Proibido
• O Twitter aparentemente retorna 200 OK, mas explica o problema no conteúdo JSON - mas isso é para tweets individuais, não para toda a API
• O Pinterest usa 451
• O plugin WordPress IP Geo Block permite que você escolha qualquer código existente

Portanto, não existe uma solução universal; você terá que escolher uma que ache melhor para sua situação. Mas, qualquer que seja a sua escolha, não deixe de explicar o problema real no corpo da resposta .

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