1. Inicio
  2. Pregunta y respuesta
  3. ¿Qué tipo MIME si JSON está siendo devuelto por una API REST?

¿Qué tipo MIME si JSON está siendo devuelto por una API REST?

2009-01-01 15 views
58

Mi API REST devuelve JSON.¿Qué tipo MIME si JSON está siendo devuelto por una API REST?

Actualmente estoy devolviendo texto/normal como el tipo MIME, pero se siente gracioso. ¿Debo devolver 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, estoy regresando como JSON

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

caso de que el código de estado HTTP permanecer en 200 OK?

Fuente

2009-01-01 ashitaka

+0

Todas las respuestas a esta parecen asumir que un navegador está involucrado. Mi aplicación REST envía y responde con mensajes json. Toda serialización y deserialización se realiza internamente por 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 a una máquina no pública muy específica. En este caso, la "application/whatever_type" hace cero diferencia, todo es solo texto. "application/json" refuerza que los datos son json, pero solo como comentario, y esto ya es lo primero que sabría cualquier persona que trabaje con la API. – mickeyf

Respuesta

70

La especificación JSON sugiere application/json, y eso parece ser compatible con el registro IETF y 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 27/06/2014: Los días en los clientes (navegadores) sólo se trabajaron con una respuesta 200 son largos pasado y el asesoramiento que prevalece para las API REST es el uso de códigos de respuesta HTTP apropiados para la respuesta, para 2xx respuestas exitosas (p. ej., 201 Creado para PUT, 204 Sin contenido para ELIMINAR) y 4xx y 5xx para todas las condiciones de error, incluidas las de la propia API.

Fuente

2009-01-01 03:22:36

+0

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. http://stackoverflow.com/questions/95554/overriding-a-mime-type-in-rails – ashitaka

+6

Por razones prácticas (digamos, por ejemplo, tiene el espantoso cliente HTTP de Flex en la mezcla), a veces tiene 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. –

+1

@ashitaka: Esa otra pregunta específicamente pregunta cómo configurar JSON a text/x-json. No afirma que sea el tipo de medio correcto para JSON. –

10

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

Fuente

2009-05-31 18:13:35

+1

Parece que David se ha ido, pero ¿alguien más puede apoyar la declaración anterior y aportar algunos argumentos, por qué esta es una buena (o mala) práctica? 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 enviar solo un error HTTP, si hay un error verdadero. – trejder

10

No, no debe 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.

Fuente

2011-05-25 09:25:03

6

El Content-type apropiado para devolver es application/json, según 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, le gustarí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, debe no 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 Sections 10.4 -10.5, y sea más preciso en el JSON.

Fuente

2011-08-01 19:15:24 LukeShu

0

Si con "API REST" quiere decir que desea seguir una arquitectura REST, entonces el tipo de medio a usar está determinado por la funcionalidad que desea exponer a través de la API REST. ¿Quieres ser capaz de crear nuevos objetos? ¿Pregunta una lista de objetos? Editar un objeto? Si es así, 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 utilizar el tipo de medio application/json, pero este tipo de medio no tiene una interfaz RESTful vinculada a hipertexto, por lo que sería un punto final en el cambio de estado.

También es completamente aceptable seguir una arquitectura 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 RESTO.

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

REST APIS must be hypertext driven

En otras palabras, si el motor de estado de la aplicación (y por tanto la API) no está siendo impulsado por hipertexto, entonces no puede ser RESTful y no puede ser ser una API REST. Período.

Asimismo, desde la discusión de ese mensaje es en este ejemplo de una aplicación REST: Lost Boys's Spam-E REST Application

Fuente

2018-03-06 04:35:35 Jason

Cuestiones relacionadas

 Cuestiones relacionadas