6 Pregunta: ¿Qué tipo de MIME si una API REST devuelve JSON?

pregunta creada en Sat, May 11, 2013 12:00 AM

Mi API REST devuelve JSON.

Actualmente estoy devolviendo text /plain como el tipo MIME, pero se siente divertido. ¿Debo devolver application/x-javascript o algún otro tipo?

La segunda pregunta es con respecto al código de estado HTTP para condiciones de error. Si mi API REST está devolviendo un estado de error, lo estoy devolviendo como JSON

 
{ result: "fail", errorcode: 1024, errormesg: "That sucked. Try again!" }

¿Debería el código de estado HTTP permanecer en 200 OK?

    
66
  1. Todas las respuestas a esto parecen suponer que hay un navegador involucrado. Mi aplicación REST envía y responde con mensajes json. Toda la serialización y la deserialización se realiza internamente en el cliente y el servidor. Los navegadores de terceros no tienen nada que ver con nada de eso, es una máquina muy específica para una máquina no pública muy específica. En este caso, "application /whatever_type" no hace ninguna diferencia, todo es solo texto. "application /json" refuerza que los datos son json, pero solo como comentarios, y esto es lo primero que cualquier persona que trabaje con la API sabría.
    2017-02-08 15: 32: 03Z
  2. @ mickeyf: el hecho de que los navegadores admitan el protocolo HTTP no significa que las aplicaciones M2M no deban hacerlo. Si desea escribir una aplicación que no admita los encabezados de tipo de contenido y de aceptación ( tools.ietf.org/html/rfc7231#section-3.1.1.5 ) puede hacerlo, sin embargo, otros desarrolladores de M2M pueden querer admitir múltiples tipos de medios (por ejemplo, application /cbor) en un estándar manera.
    2018-06-25 21: 08: 32Z
6 Respuestas                              6                         

La especificación de JSON sugiere application/json, y eso parece estar respaldado por IETF y registro IANA .

En la segunda pregunta, creo que si el manejo del mensaje falla de alguna manera, debería devolver una respuesta de error estándar y estructurada como un mensaje JSON; solo si se produce un error en la entrega del mensaje al controlador de back-end por algún motivo, debe considerar un código de error HTTP.

Actualización 2014-06-27 : los días en que los clientes (navegadores) que solo trabajaron con una respuesta 200 han pasado y el consejo que prevalece para las API de REST es usar los códigos de respuesta HTTP adecuados para la respuesta , 2xx para respuestas exitosas (por ejemplo, 201 Created for PUT; 204 No Content for DELETE) y 4xx y 5xx para todas las condiciones de error, incluidas las de la propia API.

    
77
2014-06-27 20: 57: 10Z
  1. Gracias por el enlace a la especificación JSON. Encontré otra pregunta de stackoverflow que apunta a otro tipo MIME "text /x-json". No estoy seguro de cuál es la diferencia. stackoverflow.com/questions/95554/…
    2009-01-01 03: 38: 57Z
  2. Por razones prácticas (por ejemplo, si tienes el horrible cliente HTTP de Flex en la mezcla), a veces tienes que usar 200 para todo. Sin embargo, en circunstancias normales, desea utilizar el código de estado HTTP más apropiado para la situación.
    2009-10-31 05: 08: 24Z
  3. @ ashitaka: Esa otra pregunta específicamente pregunta cómo configurar JSON para text /x-json. No hace ninguna afirmación de que sea el tipo de medio correcto para JSON.
    2011-05-25 18: 50: 17Z
19
2011-05-25 08: 39: 06Z

Prefiero responder con un estado de error HTTP y una carga útil específica de la aplicación.

    
10
2009-05-31 18: 13: 35Z
  1. Parece que David dejó el SO, pero ¿alguien más puede respaldar la afirmación anterior y aportar algunos argumentos, por qué es una práctica buena (o mala)? Según la respuesta anterior de Software Monkey, veo que devolver un error HTTP con una respuesta JSON válida es una idea equivocada. El servidor debe devolver solo el error HTTP, si hay un error verdadero.
    2013-12-18 10: 00: 01Z

No, no debes 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 útil de respuesta.

    
10
2011-05-25 09: 25: 03Z

El Content-type que debe devolverse es application/json, de acuerdo con RFC 4627 , que también registra el MIME escriba IANA (y, de hecho, aparece en la página de IANA). Por supuesto, si escribiera 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, eso es fundamentalmente sin REST. 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.

    
6
2011-08-01 19: 15: 24Z

Si por "API REST" quiere decir que quiere seguir una arquitectura REST, el tipo de medio a utilizar está determinado por la funcionalidad que desea exponer a través de la API REST. ¿Quieres poder crear nuevos objetos? ¿Quieres consultar una lista de objetos? Editar un objeto? Si es así, entonces un buen tipo de medio RESTful para usar podría ser vnd.collection + json porque define una interfaz vinculada a hipertexto para manipular una colección de objetos json.

Nota: una API RESTful podría usar la aplicación /json de tipo de medios, pero este tipo de medios no tiene una interfaz RESTful vinculada por hipertexto, por lo que sería un punto final en el cambio de estado.

También es completamente aceptable seguir una arquitectura de API web, donde las llamadas HTTP RPC devuelven objetos application /json, y otras llamadas HTTP RPC manipulan esos objetos, y no hay una interfaz de enlace de hipertexto para usar y navegar los cambios de estado. Pero esto no es REST.

Me gusta esta descripción de REST (del creador de REST):

REST APIS debe manejarse mediante hipertexto

  

En otras palabras, si el motor del estado de la aplicación (y, por tanto, la API)   no está siendo manejado por el hipertexto, entonces no puede ser RESTful y no puede   Ser una API REST. Periodo.

Además, de la discusión de esa publicación se encuentra este ejemplo de una aplicación REST: Aplicación REST Spam-E de Lost Boys

    
1
2018-03-06 04: 35: 35Z
fuente colocada aquí