json - integrar - rest api online
¿Qué tipo MIME si JSON está siendo devuelto por una API REST? (5)
Prefiero responder con un estado de error HTTP y una carga útil específica de la aplicación.
Mi API REST devuelve JSON.
Actualmente estoy devolviendo texto / normal como el tipo MIME, pero se siente gracioso. ¿Debo devolver la application/x-javascript o algún otro tipo?
La segunda pregunta es con respecto al código de estado HTTP para las condiciones de error. Si mi API REST devuelve un estado de error, regresaré como JSON
{ result: "fail", errorcode: 1024, errormesg: "That sucked. Try again!" }
¿Debería permanecer el código de estado HTTP en 200 OK ?
El tipo MIME de JSON es
application/json
http://www.ietf.org/rfc/rfc4627.txt
http://www.iana.org/assignments/media-types/application/
Más específicamente aquí:
No, no deberías devolver 200 en una condición de error.
Está bien repetir el código de estado o incluir un código de error más detallado en la carga de respuesta.
El Content-type adecuado para devolver es application/json , de acuerdo con RFC 4627 , que también registra el tipo MIME IANA (y de hecho, aparece en la página de IANA). Por supuesto, si tuviera que escribir un cliente, querría ser más liberal en lo que acepta, y también aceptar otros como text/json y text/x-json .
Ahora, si hay un error, no debe devolver HTTP 200, que es fundamentalmente no RESTful. Sé que a veces no hay una coincidencia exacta para su error, pero elija los errores 4XX (error del cliente) o 5XX (error del servidor) más cercanos en RFC 2616 Secciones 10.4 -10.5, y sea más preciso en el JSON.
La especificación JSON sugiere application/json , y eso parece ser compatible con el registro IETF e IANA .
En la segunda pregunta, creo que si el manejo de mensajes falla de alguna manera, debe devolver una respuesta de error estándar y estructurada como un mensaje JSON; solo si hay una falla al entregar el mensaje al manejador de back-end por algún motivo, si considera un código de error HTTP.
Actualización 2014-06-27 : Los días en que los clientes (navegadores) solo funcionaban con una respuesta de 200 ya pasaron y los consejos predominantes para las API RESTful es usar códigos de respuesta HTTP apropiados para la respuesta, 2xx para respuestas exitosas (por ejemplo, 201 Creado para PUT; 204 Sin contenido para DELETE) y 4xx y 5xx para todas las condiciones de error, incluidas las de la propia API.