Nuestro servicio está en 5 ciudades en este momento. Si alguien intenta llamar a nuestro servicio API desde cualquier otra ciudad, queremos lanzar este error Service not available in your area .
La pregunta es, ¿cuál es el código http apropiado para este error?
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 200. Informa cortésmente a algunos de sus usuarios de que no recibirán servicio mediante el envío de un documento que se lo indique. Y todo esto va bien.
El usuario no podrá utilizar su aplicación . Esa es una decisión consciente tomada por su lógica de negocios, 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 escuela. Cuando se diseñó HTTP, no había servicios web, no había SOAP, ni JSON, ni principios REST. Como protocolo por encima de TCP, esto ya se consideró (cerca de) el nivel de aplicación y se definieron muchos códigos de estado de alto nivel. Cuando la web comenzó a utilizarse para servicios más ricos y de alto nivel y se requería un medio común para el transporte de "envolventes", los diseñadores tomaron el sistema de HTTP HTTP en lugar de definir un protocolo más nuevo y más limpio, simplemente 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 seleccionando uno porque se acerca al estado de su aplicación y está en esa lista que una vez significó que algo puede parecer inofensivo, pero creo que enviaría un mensaje incorrecto. No desea que HTTP juegue ese rol regulador en el contexto de un servicio web.
Los errores 5xx 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
Los errores 4xx son errores del cliente: el cliente está realizando una solicitud que el servidor no puede o no está dispuesto a cumplir. En particular, un 403 indica que
el servidor entendió la solicitud, pero se niega a autorizarla. Un servidor que desea hacer público el motivo por el cual la solicitud ha sido prohibida puede describir ese motivo en la carga útil de respuesta (si corresponde). [..] Sin embargo, una solicitud podría estar prohibida por razones no relacionadas con las credenciales.
Argumentaría que 503 es claramente incorrecto, porque no es un problema temporal, no es compatible con las 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, por ejemplo,
http://example.com/API/Vienna/HailRide
o
http://example.com/API/HailRide?city=Vienna
debido a que la geolocalización de IP no es confiable, es posible que sus usuarios usen redes privadas virtuales (VPN, por sus siglas en inglés), sus usuarios pueden querer que alguien más viaje, etc. responsabilidad. 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 llamar a 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 deberían tener mensajes adicionales que regresen, 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 haces esto, la próxima vez preguntarás qué código de error HTTP devolver cuando el usuario pidió un SUV pero solo hay un Prius disponible.
Algunos tienen sentido.
403 Prohibido, por las razones que Eric Stein menciona en su respuesta . Puede utilizar la información proporcionada 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 está dispuesto a responder.
Sin embargo, también propondría 451 No disponible por razones 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 los 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 se usa normalmente en el caso de material que ha sido revocado debido a una acción de la DMCA o juicios por campañas de acoso o similares, pero espíritu y letra de la definición de respuesta dice:
Este documento especifica el estado del Protocolo de transferencia de hipertexto (HTTP) Código de uso cuando se deniega el acceso a los recursos como consecuencia de demandas.
El código en sí mismo 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 requieren aplicaciones HTTP. para entender el significado de todos los códigos de estado registrados, aunque tales la comprensión es obviamente deseable. Sin embargo, las aplicaciones DEBEN comprender la clase de cualquier código de estado, como lo indica la primera dígito, y tratar cualquier respuesta no reconocida como equivalente a la código de estado x00 de esa clase, con la excepción de que un La respuesta no reconocida NO DEBE ser almacenada en caché. Por ejemplo, si un El cliente recibe un código de estado no reconocido de 431, que puede asuma con seguridad que había algo mal con su solicitud y Trate la respuesta como si hubiera recibido un código de estado 400. De tal En los casos, los agentes de usuario DEBERÍAN presentar al usuario la entidad devuelta con la respuesta, ya que es probable que esa entidad incluya Información legible que explicará el estado inusual.
Siempre puede crear su propio código de estado en el rango 400 para que lo use su API y Aplicación cliente.
403 es el código, pero debes hacer coincidir la descripción del error con el código que estás dando: si dices
Service not available in your area.
entonces debes dar un 404 porque dices que el servicio no está disponible . si dices
You are not authorized for this service in your area.
entonces debes dar un 403 porque dices que la persona que llama no está autorizada .
Iría por el segundo.
Al principio pensé en 503 porque la descripción "servicio no disponible" parece estar en línea con el problema, pero mirando a definiciones , 503 es realmente específico a la indisponibilidad 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 entiende, pero que el servidor no está dispuesto a satisfacerlo. Esto podría 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 de este código.
A menos que alguien haya ideado un nuevo código para esto, 403 o 404 parecen ser los más cercanos.
Hay un borrador actual de Internet (que caducará el 31 de diciembre de 2018) que propone enmiendas al estado HTTP 451 no disponible por motivos legales . El borrador sugiere que una respuesta 451 debe contener un encabezado geo-scope-block que debe "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 utilizado "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 coloca en el operador)". / p>
Entonces, asumiendo que no tiene 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 opiniones", así que veamos qué están haciendo los demás:
Entonces, no hay una solución universal, solo tendrá que elegir una que crea que se adapte mejor a su situación. Pero lo que elija, asegúrese de explicar el problema real en el cuerpo de la respuesta .
Diría que no sería incorrecto especificar un código de estado HTTP personalizado, como RubberDuck ya ha respondido . Un código de estado personalizado en el rango 400 podría ser incluso una buena llamada, porque eso definitivamente llamará la atención de los desarrolladores si ven algo como "estado HTTP 499". Un "403" es demasiado fácil de pasar ya que " está bien, así que mi contraseña fue incorrecta. Intentamos otra cosa ", y eso resulta en horas perdidas.
Lea otras preguntas en las etiquetas api-design api http