¿Cuál debería ser el código de estado http para el error "Servicio no disponible en su área"?

Nuestro servicio se encuentra en 5 ciudades en este momento. Si alguien intenta llamar a nuestro API de servicio desde cualquier otra ciudad, queremos lanzar este error Service not available in your area.

La pregunta es, ¿cuál sería el código http apropiado para este error?

• 503 Servicio no Disponible
• 403: prohibido

¿o algo mas?

Cualquier código de error HTTP sería inapropiado. No hay ningún error o problema de ningún tipo desde una perspectiva HTTP, por lo que debería ser algo en el rango de 200. Informa educadamente a algunos de sus usuarios que no serán atendidos mediante el envío de un documento que se lo indique. Y todo esto va bien.

El usuario no podrá usar su aplicación . Esa es una decisión consciente tomada por la lógica de su negocio, no un contratiempo. En el nivel HTTP, todo es honky dory.

Editar

Parece que lo que estamos viendo aquí es un choque entre la vieja escuela y la nueva. Cuando se diseñó HTTP, no había servicios web, no había principios SOAP, JSON, REST. Como un protocolo por encima de TCP, esto ya se consideraba (cercano) al nivel de aplicación y se definieron muchos códigos de estado de alto nivel. Cuando la web comenzó a usarse para servicios más ricos y de alto nivel y se requería un medio común para transportar "sobres", los diseñadores utilizaron HTTP en lugar de definir un protocolo más nuevo y limpio, solo porque HTTP era ubicuo.

Por lo tanto, en un contexto de servicio web moderno, HTTP es de hecho poco más que una capa de transporte tonta y la mayoría de sus códigos pueden considerarse no aplicables u obsoletos. Solo elijo uno porque se acerca al estado de su aplicación y está en esa lista que alguna vez significó que algo puede parecer inofensivo, pero creo que enviaría un mensaje incorrecto. No desea que HTTP desempeñe ese papel regulador en un contexto de servicio web.

5xxlos errores son errores del servidor: algo salió mal en el servidor. En particular, un 503 indica que:

el servidor actualmente no puede manejar la solicitud debido a una sobrecarga temporal o mantenimiento programado

4xxlos errores son errores del cliente: el cliente realiza una solicitud que el servidor no puede o no desea cumplir. En particular, un 403 indica que

el servidor entendió la solicitud pero se niega a autorizarla. Un servidor que desea hacer público por qué se ha prohibido la solicitud puede describir ese motivo en la carga útil de respuesta (si corresponde). [..] Sin embargo, una solicitud podría estar prohibida por razones ajenas a las credenciales.

Yo diría que 503es claramente incorrecto, porque este no es un problema temporal, no se admiten solicitudes en esa área, punto. Se podría argumentar que eventualmente espera apoyar el área, pero la intención del código es incluir un encabezado que indique cuándo el cliente puede volver a intentarlo. "En 6 meses" no se adhiere a la intención.

403 es una mejor opción porque su servicio simplemente prohíbe las solicitudes de ciertas configuraciones regionales.

Ninguno de esos.

Si su API está bien diseñada, la URL incluye el nombre de la ciudad, p. Ej.

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

o

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

dado que la geolocalización de IP no es confiable, sus usuarios pueden estar usando VPN, sus usuarios pueden querer llevar a alguien más, etc. Sugerir una ciudad basada en la ubicación del usuario es responsabilidad del cliente API . Por lo general, el cliente tiene recursos mucho mejores para determinar la ubicación del usuario de todos modos (por ejemplo, el servicio de ubicación de un dispositivo móvil).

Una vez que hayas hecho eso, la respuesta correcta a

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

o

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

se vuelve obvio: 404 No encontrado : no existe ningún recurso para detener un viaje en SomeUnsupportedCity.

Esto parece una pregunta de agujero redondo / clavija cuadrada. ¿Por qué su única respuesta debe ser un código HTTP? Los códigos de error HTTP no pueden cubrir todos los casos de uso.

Todas sus llamadas a la API deben tener mensajes adicionales que vuelvan, es decir, un pequeño mensaje de error JSON. Dales un 403 (porque realmente no tienen permiso para usar la API dada la ubicación) y devuelve un poco de información adicional como sugieres.

Si no hace esto, la próxima vez preguntará qué código de error HTTP devolverá cuando el usuario solicitó un SUV, pero solo hay un Prius disponible.

Algunos tienen sentido.

403 Prohibido, por las razones que Eric Stein menciona en su respuesta . Puede usar diversa información provista por la solicitud para determinar dónde está el cliente y quién es el cliente y, en base a esa solicitud, el servidor no puede o no quiere responder.

Sin embargo, también propondría 451 No disponible por motivos legales como un posible estado de devolución para algunos casos. Este estado espera que incluya (en los encabezados) un enlace a la legislación pertinente. Es específicamente para casos en los que no es legal que el cliente acceda a sus recursos, y no existe un caso más general del cliente en una región o área no admitida.

Evitaría la serie 5xx de estados, que a menudo indican problemas técnicos del lado del servidor. No parece ser el caso aquí.

Si la restricción se debe a razones legales, entonces el código de error HTTP apropiado es HTTP 451, "No disponible por razones legales".

Esto generalmente se usa en el caso de material que ha sido revocado debido a acciones de DMCA o demandas debido a campañas de acoso o similares, pero el espíritu y la letra de la definición de respuesta establece:

Este documento especifica un código de estado del Protocolo de transferencia de hipertexto (HTTP) para usar cuando se niega el acceso a los recursos como consecuencia de demandas legales.

El código en sí es una referencia a Fahrenheit 451 por Ray Bradbury.

La gente a menudo olvida que los códigos de estado HTTP son extensibles.

Los códigos de estado HTTP son extensibles. No se requiere que las aplicaciones HTTP comprendan el significado de todos los códigos de estado registrados, aunque dicha comprensión es obviamente deseable. Sin embargo, las aplicaciones DEBEN comprender la clase de cualquier código de estado, como lo indica el primer dígito, y tratar cualquier respuesta no reconocida como equivalente al código de estado x00 de esa clase, con la excepción de que una respuesta no reconocida NO DEBE almacenarse en caché. Por ejemplo, si el cliente recibe un código de estado no reconocido de 431, puede asumir con seguridad que hubo un error en su solicitud y tratar la respuesta como si hubiera recibido un código de estado 400. En tales casos, los agentes de usuario DEBERÍAN presentar al usuario la entidad devuelta con la respuesta,

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

Siempre puede crear su propio código de estado en el rango 400 para que lo use su API y la aplicación cliente.

Al principio pensé en 503 porque la descripción "servicio no disponible" parece alinearse con el problema, pero mirando las definiciones , 503 es realmente específico para la falta de disponibilidad del servidor. Luego, pensando más, le está diciendo al cliente que hay un problema con la solicitud, no que hay un problema del lado del servidor.

403 está más cerca porque le está diciendo al usuario que recibió el mensaje y lo comprende, pero que el servidor no está dispuesto a satisfacerlo. Esto puede ser confuso, por lo que se puede agregar una explicación textual para describir el escenario. Según el RFC, 404 también es un sustituto válido para este código.

A menos que alguien haya ideado un nuevo código para esto, 403 o 404 parecen ser los más cercanos.

Debe hacer coincidir la descripción del error con el código que está dando:

• si lo dice Service not available in your area., debe dar un 404porque afirma que el servicio no está disponible .

• si lo dice You are not authorized for this service in your area., debe dar un 403porque afirma que la persona que llama no está autorizada .

Yo iría por el segundo.

Hay un borrador actual de Internet (que vencerá el 31 de diciembre de 2018) que propone enmiendas al estado HTTP 451 No disponible por razones legales . El borrador sugiere que una respuesta 451 debería contener un geo-scope-blockencabezado que debería "corresponder a una lista separada por comas de códigos de país alfa-2 definidos en [ISO.3166-1]". Sin embargo, el borrador también especifica que el código 451 no debe ser usado "por un operador para denegar el acceso a un recurso sobre la base de una política especificada por el operador (en oposición a una demanda legal que se aplica al operador)".

Entonces, suponiendo que no tenga una demanda legal para el geobloque, 451 no es el código correcto. ¿Cuál es el código correcto entonces? Bueno, muchas otras respuestas ya han sugerido 403 Prohibido , pero todas parecen estar "basadas en la opinión", así que veamos qué están haciendo los demás:

• Amazon CloudFront utiliza 403 prohibido
• Aparentemente, Twitter devuelve 200 OK, pero explica el asunto en el contenido JSON , pero eso es para tweets individuales, no para toda la API
• Pinterest usa 451
• El complemento WordPress IP Geo Block le permite elegir cualquier código existente

Por lo tanto, no hay una única solución universal, solo tendrá que elegir la que mejor se adapte a su situación. Pero cualquiera que elija, asegúrese de explicar el problema real en el cuerpo de respuesta .

Yo diría que no habría nada de malo en solo especificar un código de estado HTTP personalizado, como ya respondió RubberDuck . Un código de estado personalizado en el rango de 400 podría incluso ser una buena opción, porque definitivamente atraerá la atención de los desarrolladores si ven algo como "HTTP status 499". Un "403" es demasiado fácil de pasar como " OK, así que me equivoqué de contraseña, intentemos otra cosa ", y eso resulta en horas perdidas.