REST API error retorno buenas prácticas [cerrado]

Un gran recurso para elegir el código de error HTTP correcto para su API: http://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html

Un extracto del artículo:

Por dónde empezar:

2XX / 3XX:

4XX:

5XX:

La opción principal es si desea tratar el código de estado HTTP como parte de su API REST o no.

Ambas formas funcionan bien. Estoy de acuerdo en que, estrictamente hablando, una de las ideas de REST es que debe utilizar el código de estado HTTP como parte de su API (devolver 200 o 201 para una operación exitosa y un 4xx o 5xx dependiendo de varios casos de error.) However, there are no REST police. Puedes hacer lo que quieras. He visto APIs no REST mucho más atroces que se llaman " RESTful."

En este punto (agosto, 2015) recomiendo que use el código de estado HTTP como parte de su API. Ahora es mucho más fácil ver el código devuelto al usar frameworks de lo que era en el pasado. En particular, ahora es más fácil ver el caso de devolución no 200 y el cuerpo de respuestas no 200 de lo que era en el pasado.

El código de estado HTTP es parte de su api

1. Tendrá que elegir cuidadosamente los códigos 4xx que se ajusten a sus condiciones de error. Usted puede incluir un mensaje rest, xml o texto plano como carga útil que incluye un subcódigo y un comentario descriptivo.

2. Los clientes necesitarán usar un marco de software que les permita obtener el código de estado a nivel HTTP. Por lo general, puede hacerlo, no siempre es sencillo.

3. Los clientes tendrán que distinguir entre los códigos de estado HTTP que indican un error de comunicación y sus propios códigos de estado que indican un nivel de aplicación cuestión.

El código de estado HTTP NO forma parte de tu api

1. El código de estado HTTP siempre será 200 si su aplicación recibió la solicitud y luego respondió (tanto en casos de éxito como de error)

2. TODAS sus respuestas deben incluir información de "sobre" o "encabezado". Normalmente algo como:

   envelope_ver: 1.0
   status:  # use any codes you like. Reserve a code for success. 
   msg: "ok" # A human string that reflects the code. Useful for debugging.
   data: ...  # The data of the response, if any.

3. Este método puede ser más fácil para los clientes, ya que el estado de la respuesta siempre está en el mismo lugar (sin sub-códigos necesario), sin límites en los códigos, sin necesidad de obtener el código de estado de nivel HTTP.

Aquí hay un post con una idea similar: http://yuiblog.com/blog/2008/10/15/datatable-260-part-one /

Cuestiones principales:

1. Asegúrese de incluir números de versión para que pueda cambiar más adelante la semántica de la api si es necesario.

2. Documento...

Recuerde que hay más códigos de estado que los definidos en los RFC HTTP/1.1, el registro IANA está en http://www.iana.org/assignments/http-status-codes . Para el caso que mencionaste el código de estado 507 suena bien.

Como otros han señalado, tener una entidad de respuesta en un código de error es perfectamente permisible.

Recuerde que los errores 5xx son del lado del servidor, también conocido como el cliente no puede cambiar nada a su solicitud para hacer que la solicitud pase. Si se excede la cuota del cliente, eso definitivamente no es un error del servidor, por lo que se debe evitar 5xx.

Sé que esto es extremadamente tarde para la fiesta, pero ahora, en el año 2013, tenemos algunos tipos de medios para cubrir el manejo de errores de una manera distribuida (RESTful) común. Véase " vnd.error", application / vnd.error + json ( https://github.com/blongden/vnd.error) y "Detalles del problema para las API HTTP", aplicación / problema + json ( https://tools.ietf.org/html/draft-nottingham-http-problem-05).

Hay dos tipos de errores. Errores de aplicación y errores HTTP. Los errores HTTP son solo para que su controlador AJAX sepa que las cosas salieron bien y no deben usarse para nada más.

5xx Error del servidor

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates (RFC 2295 )
507 Insufficient Storage (WebDAV) (RFC 4918 )
509 Bandwidth Limit Exceeded (Apache bw/limited extension)
510 Not Extended (RFC 2774 )

2xx Éxito

200 OK
201 Created
202 Accepted
203 Non-Authoritative Information (since HTTP/1.1)
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status (WebDAV)

Sin embargo, cómo diseñar los errores de su aplicación depende realmente de usted. Stack Overflow, por ejemplo, envía un objeto con response, data y message propiedades. Creo que la respuesta contiene true o false para indicar si la operación fue exitosa (generalmente para operaciones de escritura). Los datos contienen la carga útil (generalmente para operaciones de lectura) y el mensaje contiene cualquier metadata adicional o mensajes útiles (como mensajes de error cuando response es false).

De acuerdo. La filosofía básica de REST es utilizar la infraestructura web. Los códigos de estado HTTP son el marco de mensajería que permite a las partes comunicarse entre sí sin aumentar la carga útil HTTP. Son códigos universales ya establecidos que transmiten el estado de la respuesta, y por lo tanto, para ser verdaderamente RESTful, las aplicaciones deben usar este marco para comunicar el estado de la respuesta.

Enviar una respuesta de error en un sobre HTTP 200 es engañoso, y obliga a cliente (consumidor api) para analizar el mensaje, muy probablemente de una manera no estándar o propietaria. Esto tampoco es eficiente: obligará a sus clientes a analizar la carga útil HTTP cada vez para comprender el estado de respuesta" real". Esto aumenta el procesamiento, agrega latencia y crea un entorno para que el cliente cometa errores.

Modelado de su api en las 'mejores prácticas' existentes podría ser el camino a seguir. Por ejemplo, así es como Twitter maneja los códigos de error https://developer.twitter.com/en/docs/basics/response-codes

Por favor, apégate a la semántica del protocolo. Use 2xx para respuestas exitosas y 4xx, 5xx para respuestas de error, ya sean excepciones de su negocio u otras. Si el uso de 2xx para cualquier respuesta hubiera sido el caso de uso previsto en el protocolo, no tendrían otros códigos de estado en primer lugar.

No olvide los errores 5xx también para los errores de aplicación.

En este caso, ¿qué pasa con 409 (Conflicto)? Esto supone que el usuario puede solucionar el problema eliminando los recursos almacenados.

De lo contrario 507 (no completamente estándar) también puede funcionar. No usaría 200 a menos que uses 200 para errores en general.

Si se excede la cuota de cliente es un error de servidor, evite 5xx en esta instancia.