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

51

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?

Shaharyar
fuente
52
"Si alguien intenta llamar a nuestro API de servicio desde cualquier otra ciudad", tenga en cuenta que la geolocalización de IP a menudo es incorrecta, si prohíbe a cualquier usuario cuya IP geolocalice a una ciudad diferente, es muy probable que bloquee a usuarios legítimos.
Peter Green
43
¿No se me permite llamar a mi hijo que está en otra ciudad y necesita venir al aeropuerto para visitarme?
Dawood dice reinstalar a Mónica el
29
Si bien no es una respuesta a la pregunta, HTTP 451 (RFC 7725) puede ser útil para futuros lectores que encuentren esta pregunta. Su propósito principal es indicar que el contenido no está disponible debido a una solicitud legal, acción o restricción (derechos de autor, orden judicial, etc.)
Tyzoid
34
Si no hay nada de malo con la conectividad de red, la autenticación, sin errores internos en la aplicación y la entrada sintácticamente válida, no debería haber un mensaje de error. Con "no ofrecemos nuestro servicio en esta área", dejó problemas tecnológicos y entró en problemas comerciales, por lo que no estoy seguro de que un error HTTP sea apropiado. Creo que debería dar un 200 y (o 302 y redirigir a) un mensaje apropiado sobre "lo siento, nuestro servicio aún no está disponible en su área. Pero nos estamos expandiendo. ¡Vuelva a consultar a fines de 2019!" o lo que se le ocurra al departamento de marketing.
ivanivan
77
No queda claro a partir de la pregunta si quiere bloquear todo el acceso a la API en función de la ubicación del equipo cliente (¿geo IP?) O si está solicitando el código de respuesta para una solicitud de API fallida en particular (por ejemplo, book? Address = 123_example_st_london) . ¿La ubicación es parte de la entrada o tiene la ubicación del cliente de alguna otra manera?
Ben

Respuestas:

101

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.

Martin Maat
fuente
56
Según esta lógica, cualquier error de la aplicación debe devolverse como 200. Y todas las solicitudes deben ser POST, incluso eliminaciones. Este enfoque trata HTTP como un protocolo de transporte opaco, como TCP. Esta no es la forma en que generalmente se tratan las API de servicios web: intentan aprovechar la semántica HTTP como un lenguaje estándar para las API. ¿Por qué no devolver 401 para No autorizado, en lugar de devolver 200 con un código de error personalizado y no estándar?
Avner Shahar-Kashtan
31
Según esta lógica, ninguna aplicación debería devolver una respuesta en el rango de 400. Este es precisamente el tipo de condición para la que es el rango de 400 respuestas. Además, ¿su primera oración se aplica a todas las respuestas futuras, así como a las que se publicaron antes de la suya?
Dawood dice que reinstalará a Mónica el
31
Tengo que estar de acuerdo aquí en que esto es solo un simple 200. El usuario ha hecho una pregunta, la hemos entendido, sabemos la respuesta correcta y le hemos proporcionado la respuesta (que resulta ser "No"). Todo está bien en tierra HTTP.
Lee Daniel Crocker
8
Jeje ... viaje rápido de "esto no es realmente un error" a "entonces, ¿estás diciendo que nada es un error?"
svidgen
28
Esta. "Intentó acceder a una URL que no existe" es muy diferente de "Nuestra empresa no opera en su área". Solo uno tiene algo que ver con HTTP.
CJ Dennis
87

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.

Eric Stein
fuente
403 es para casos en los que el acceso está prohibido y el cliente no puede hacer nada al respecto. Pero en este caso el cliente puede (subir al automóvil con su computadora portátil o teléfono), por lo que 403 es inapropiado.
gnasher729
2
@ gnasher729 Los errores 4xx son para cosas que el cliente podría solucionar, que incluye 403. La especificación (vinculada) establece específicamente que el cliente puede volver a intentarlo con diferentes credenciales (suponiendo que las credenciales fueran el problema).
jaxad0127
22
@ gnasher729 403 no significa que el humano no pueda hacer nada al respecto. Significa que el navegador no puede hacer nada al respecto. El humano siempre puede restablecer la contraseña, hablar con el administrador o, en este caso, mudarse a otra ciudad.
slebetman
1
@ gnasher729 El cliente no es el usuario.
Capitán Man
10
5xx = Vaya, está mal, espera mientras solucionamos el problema. 4xx = Lo sentimos, pero por política no podemos atender su solicitud en este momento. He aquí por qué ...
candied_orange
46

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.

Heinzi
fuente
66
Esta debería ser la respuesta aceptada: el diseño de la API no se trata solo de cumplir con los códigos numéricos antiguos, y el escenario sobre vpn, etc. es bastante realista.
Edoardo
10
Tengo que estar en desacuerdo con esto. Incluir el nombre de la ciudad en la URL podría ocasionar todo tipo de problemas en el futuro, ya que obliga al cliente a determinar el nombre de una ciudad en función de la ubicación, y es posible que no le guste el resultado. Por ejemplo, ¿estás en Los Ángeles o Beverly Hills? Londres o Westminster? ¿Qué sucede si el cliente piensa que está en Richardson, pero desea una API para servir a toda el área de Dallas? Sería una mejor idea para el cliente simplemente suministrar las ubicaciones de recogida / devolución; el servidor puede determinar si están dentro del área de servicio y responder en consecuencia.
Zach Lipton
11
@ZachLipton Estoy bastante seguro de que los nombres de las ciudades fueron solo un ejemplo, depende de las reglas comerciales reales del OP cómo definen "ciudad" o "ubicación". También podría ser una coordenada.
Bergi
1
@ZachLipton no, el punto aquí es que el servicio no use la IP del cliente para comprender la ubicación, eso es simplemente incorrecto
Edoardo
3
@eddyce Estoy de acuerdo en que usar la IP del cliente es una mala idea por muchas razones. Estoy diciendo que / API / Vienna / HailRide también es propenso a problemas, porque requiere que el cliente convierta ubicaciones en nombres de ciudades, y eso no es un mapeo 1 a 1 que corresponda con las áreas en las que una empresa hace negocios.
Zach Lipton
26

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.

stdunbar
fuente
55
+1 para tu última oración. Lo resume muy bien.
LoztInSpace
1
Bueno, eso claramente debería ser una redirección 3xx de algún tipo. ;)
Nombre real redactado el
El último caso probablemente justifica una respuesta 4xx de algún tipo: el usuario realizó una solicitud que el servidor no puede cumplir. Sería 400 si la elección fuera algún tipo de entrada no válida o 404 si la ubicación en sí misma simplemente no existe. Aunque podría ser 200 si es un criterio de búsqueda y simplemente no hay coincidencias.
jpmc26
11

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í.

Thomas Owens
fuente
Probablemente la razón en este caso es que no tiene sentido decirle al usuario sobre los automóviles que no están en su ciudad. Así que no es el caso para 451
max630
44
@ max630 No puede suponer eso a partir de la pregunta. 403 Prohibido es muy probablemente la elección correcta. Sin embargo, si hay restricciones legales en el servicio, se puede usar el 451 más específico. 451 a menudo se ve como una versión más específica de 403 para casos de uso muy particulares, por lo que tiene sentido mencionarlo.
Thomas Owens
8
@ max630: es completamente posible que 451 sea apropiado aquí. Muchas jurisdicciones requieren que los operadores de este tipo de servicio estén registrados en las autoridades regionales antes de proporcionar el servicio. En realidad, se les podría prohibir legalmente procesar ciertas solicitudes si se originan fuera del área.
Julio
5

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.

mullido
fuente
3

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.

RubberDuck
fuente
Hmm ... puede no ser necesario si la solicitud incluye un Expect token;city="Albequerque"encabezado. Entonces la respuesta más apropiada sería 417, la expectativa falló. tools.ietf.org/html/rfc2616#section-10.4.18 Suponiendo, por supuesto, que esto es para un servicio web.
Berin Loritsch
Tal vez no sea necesario @BerinLoritsch, pero en lugar de intentar forzar el ajuste de una situación en un código existente, puede ser mejor simplemente despejar y usar uno personalizado.
RubberDuck
0

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.

JimmyJames
fuente
Definitivamente no es un código 5xx, porque eso implica que intentar exactamente la misma solicitud más tarde podría tener éxito. Un código 4xx definitivamente le dice al cliente que no intente nuevamente sin cambiar al menos parte de la solicitud (en este caso, el campo "ubicación del servicio").
Toby Speight
0

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.

Edoardo
fuente
66
404 no se trata de disponibilidad , se trata de existencia . Solo porque un servicio no está disponible en algunas circunstancias, no debe proporcionar una respuesta 404 a menos que desee que las personas crean que no existe en absoluto. Una respuesta 404 no tendría sentido para esta situación.
Julio
@jules De acuerdo con la especificación para 403 (que podría estar desactualizada): "Si el servidor no desea que esta información esté disponible para el cliente, se puede usar el código de estado 404 (No encontrado) ". Entonces, si 403 está bien, entonces 404 también lo estaría, pero no necesariamente por la razón dada.
JimmyJames
@JimmyJames: sí, está dentro de las especificaciones, pero es una muy mala idea porque hace que los problemas de depuración sean extremadamente difíciles. No es lo que quieres en una API.
Julio
3
@Jules El servicio no existe en algunas áreas. Al igual que hay muchas tiendas pequeñas que solo existen en mi ciudad, entonces preguntarle a su dirección en otra ciudad la respuesta correcta es "no existe".
Andy
ehmm hablar de "existencia" sobre una ruta de URL de servicio es lo menos filosófico, por razones de claridad, una vez que publica una ruta, debe proporcionar una respuesta, 403 es el camino a seguir en este caso, con algún tipo de descripción verbal de la situación.
Edoardo
0

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:

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.

Cero uno
fuente