¿Puedo usar razones personalizadas para un código de estado HTTP para diferenciar entre errores para una API REST?

Question

Quiero diferenciar entre tipos separados de errores "No encontrados". Por ejemplo, dada la siguiente petición:

GET /author/Adams/works/HHGTTG

O bien el autor podría ser 'no encontrado' o el trabajo podría be'not encontrado' y quiero diferenciar entre los dos.

estado: 404 - autor no encontró
estado: 404 - El trabajo no encontrado

De acuerdo con la especificación de la frase la razón puede ser cambiado. http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html

6.1.1 Código de Estado y de frases

razón ... la razón frases enumerados aquí son sólo recomendaciones - Pueden ser reemplazados por sus equivalentes locales sin afectar el protocolo ...

¿También es aceptable usar dos frases únicas para el mismo código de estado?

Y, ¿este es un enfoque sensato o hay una mejor convención para indicar errores más granulares?

En última instancia, quiero tener una biblioteca de cliente que pueda arrojar una excepción AuthorNotFound o WorkNotFound en lugar de una excepción genérica AuthorOrWorkNotFound.

Answer 1

Al utilizar el enfoque de "sombra" que no se encuentra, se puede hacer uso de 404 con cuerpo de la respuesta:

• uso de estado 404 con datos de texto ('autor no encontrado', 'trabajo no encontrado'). Para ser más lenguaje flexible que podría utilizar etiquetas (como error.author.notFound)
• recurso más estructurado y mucho más fácil de analizar "subcódigos" (por ejemplo, 10 indica autor no encontraron, no se encontró el 11 de usuario).

Aún NO recomiendo los sub-códigos mencionados anteriormente, agregan mucha complejidad y esfuerzo de mantenimiento para una interfaz HTTP uniforme. Estructura tu biblioteca api-client de manera diferente. Déjalo llamar primero al /author/adams/work/11. Si devuelve 404, llame al /author/adams/ para averiguar si fue el autor faltante el que causó el 404. Luego, puede lanzar las respectivas excepciones NotFound.

Otra alternativa es diseñar la aplicación api-client final de manera diferente. Primero debe llamar al /author/adams; si no, 404 procedería /author/adams/work. Entonces, naturalmente, la aplicación en sí misma está descendiendo en el camino. Pero esto, por supuesto, solo funciona si el flujo de su página dentro de la interfaz se adapta a esta secuencia de llamadas.

Answer 2

Puede hacer que el cuerpo de la respuesta HTTP contenga un mensaje que puede analizar con información adicional.

El mensaje de estado HTTP en el código de estado (en la respuesta) puede ser cualquier cosa que desee y no afectará a ningún cliente. Los clientes HTTP normalmente ignoran el texto del mensaje.