Pregunta

He estado jugando con JSON Durante algún tiempo, simplemente lo publiqué como texto y no ha lastimado a nadie (que yo sepa), pero me gustaría comenzar a hacer las cosas correctamente.

He visto entonces muchos supuestos "estándares" para el tipo de contenido JSON:

application/json
application/x-javascript
text/javascript
text/x-javascript
text/x-json

¿Pero cuál es la correcta o la mejor?Supongo que existen problemas de seguridad y compatibilidad con el navegador que varían entre ellos.

Sé que hay una pregunta similar, ¿Qué tipo de MIME si una API REST devuelve JSON?, pero me gustaría una respuesta un poco más específica.

¿Fue útil?

Solución

Para texto JSON:

application/json

  

El tipo de medio MIME para texto JSON es application/javascript . La codificación predeterminada es UTF-8. (Fuente: RFC 4627 ).

Para JSONP (javascript ejecutable) con devolución de llamada:

  

text/html

Aquí hay algunas publicaciones de blog que se mencionaron en los comentarios que son relevantes.

Otros consejos

IANA ha registrado el tipo MIME oficial para JSON como application/json .

Cuando se le preguntó por qué no text/json, Crockford parece haber dicho que JSON no es realmente JavaScript ni texto, y que también era más probable que IANA entregara application/* que text/*.

Más recursos:

Para JSON:

Content-Type: application/json

Para JSON-P :

Content-Type: application/javascript

Por supuesto, el tipo de medio MIME correcto para JSON es application/json, pero es necesario darse cuenta de qué tipo de datos se espera en su aplicación.

Por ejemplo, uso Ext GWT y la respuesta del servidor debe ser text / html pero contiene datos JSON.

Cliente, Ext GWT form listener

uploadForm.getForm().addListener(new FormListenerAdapter()
{
    @Override
    public void onActionFailed(Form form, int httpStatus, String responseText) 
    {
        MessageBox.alert("Error");
    }

    @Override
    public void onActionComplete(Form form, int httpStatus, String responseText) 
    {
        MessageBox.alert("Success");
    }
});

En caso de utilizar el tipo de respuesta application / json , el navegador me sugiere que guarde el archivo.

Fragmento de código fuente del lado del servidor utilizando Spring MVC

return new AbstractUrlBasedView() 
{
    @SuppressWarnings("unchecked")
    @Override
    protected void renderMergedOutputModel(Map model, HttpServletRequest request,
                                           HttpServletResponse response) throws Exception 
    {
        response.setContentType("text/html");
        response.getWriter().write(json);
    }
};

JSON:

La respuesta son datos generados dinámicamente, de acuerdo con los parámetros de consulta pasados ​​en la URL.

Ejemplo:

{ "Name": "Foo", "Id": 1234, "Rank": 7 }

Tipo de contenido: application/json


JSON-P:

JSON con relleno.La respuesta son datos JSON, con una llamada de función a su alrededor.

Ejemplo:

functionCall({"Name": "Foo", "Id": 1234, "Rank": 7});

Tipo de contenido: application/javascript

Si está utilizando Ubuntu o Debian y sirve archivos .json a través de Apache, es posible que desee servir los archivos con el tipo de contenido correcto. Estoy haciendo esto principalmente porque quiero usar la extensión de Firefox JSONView

El módulo Apache mod_mime ayudará a hacer esto fácilmente. Sin embargo, con Ubuntu necesita editar el archivo /etc/mime.types y agregar la línea

application/json json

Luego reinicie Apache:

sudo service apache2 restart

Si llama a los servicios web ASP.NET desde el lado del cliente, debe usar application/json para que funcione. Creo que esto es lo mismo para jQuery y Ext frameworks.

El tipo de contenido correcto para JSON es application/json A MENOS QUE esté usando JSONP , también conocido como JSON con relleno , que en realidad es JavaScript, por lo que el tipo de contenido correcto sería application/javascript.

No hay duda de que application/json es el mejor MIME para una respuesta JSON.

Pero tenía algo de experiencia donde tuve que usar application/x-javascript debido a algunos problemas de compresión. Mi entorno de alojamiento es alojamiento compartido con GoDaddy . No me permiten cambiar las configuraciones del servidor. Agregué el siguiente código a mi web.config archivo para comprimir las respuestas.

<httpCompression>
    <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll"/>
    <dynamicTypes>
        <add mimeType="text/*" enabled="true"/>
        <add mimeType="message/*" enabled="true"/>
        <add mimeType="application/javascript" enabled="true"/>
        <add mimeType="*/*" enabled="false"/>
    </dynamicTypes>
    <staticTypes>
        <add mimeType="text/*" enabled="true"/>
        <add mimeType="message/*" enabled="true"/>
        <add mimeType="application/javascript" enabled="true"/>
        <add mimeType="*/*" enabled="false"/>
    </staticTypes>
</httpCompression>
<urlCompression doStaticCompression="true" doDynamicCompression="true"/>

Al usar esto, las páginas .aspx se comprimieron con g-zip pero las respuestas JSON no. Agregué

<add mimeType="application/json" enabled="true"/>

en las secciones de tipos estático y dinámico. Pero esto no comprime las respuestas JSON en absoluto.

Después de eso, eliminé este tipo recién agregado y agregué

<add mimeType="application/x-javascript" enabled="true"/>

en las secciones de tipos estático y dinámico, y cambió el tipo de respuesta en

.ashx (controlador asincrónico) a

application/x-javascript

Y ahora descubrí que mis respuestas JSON estaban comprimidas con g-zip. Así que personalmente recomiendo usar

<*>

solo si desea comprimir sus respuestas JSON en un entorno de alojamiento compartido . Porque en el alojamiento compartido, no le permiten cambiar IIS configuraciones.

Solo cuando uso application/json como MIME tengo lo siguiente (a partir de noviembre 2011 con las versiones más recientes de Chrome, Firefox con Firebug ):

  • No más advertencias de Chrome cuando el JSON se carga desde el servidor.
  • Firebug agregará una pestaña a la respuesta que le mostrará los datos JSON formateado Si el tipo MIME es diferente, solo aparecerá como 'Contenido de respuesta'.

No todo funciona para el tipo de contenido application/json.

Si está utilizando Ext & nbsp; JS enviar formulario para cargar el archivo, sea consciente de que el navegador analiza la respuesta del servidor para crear el documento para el <iframe>.

Si el servidor está utilizando JSON para enviar el objeto devuelto, entonces el encabezado Content-Type debe establecerse en text/html para indicarle al navegador que inserte el texto sin cambios en el cuerpo del documento.

Consulte la documentación de la API Ext JS 3.4.0 .

JSON es un lenguaje específico de dominio (DSL) y un formato de datos independiente de JavaScript, y como tal tiene su propio MIME tipo, application/json. El respeto por los tipos MIME está, por supuesto, orientado al cliente, por lo que text/plain puede hacerlo para la transferencia de bytes, pero entonces estaría empujando la interpretación al dominio de la aplicación del proveedor innecesariamente - text/HTML. ¿Transferirías XML a través de <=>?

Pero honestamente, su elección del tipo MIME es un consejo para el cliente sobre cómo interpretar los datos: <=> o <=> (cuando no es HTML) es como borrar el tipo, es tan poco informativo como hacer todos sus objetos de tipo Objeto en un lenguaje escrito.

Ningún tiempo de ejecución del navegador que conozco tomará un documento JSON y lo pondrá a disposición automáticamente en tiempo de ejecución como un objeto accesible a JavaScript sin intervención, pero si está trabajando con un cliente paralítico, eso es un asunto completamente diferente. Pero esa no es toda la historia: RESTful Los servicios JSON a menudo no tienen tiempos de ejecución de JavaScript, pero no se detiene utilizando JSON como un formato de intercambio de datos viable. Si los clientes están paralizados ... entonces consideraría quizás la inyección de HTML a través de un servicio de plantillas Ajax .

Aplicación / JSON!

Si se encuentra en un entorno del lado del cliente, es obligatorio investigar sobre la compatibilidad entre navegadores para una aplicación web con buen soporte.

El tipo de contenido HTTP correcto sería application/json, como otros ya están resaltados también, pero algunos clientes no lo manejan muy bien, por eso jQuery recomienda el text/html predeterminado.

La respuesta correcta es:

Content-Type: application/json

Como muchos otros han mencionado, application/json es la respuesta correcta.

Pero lo que aún no se ha explicado es lo que significan las otras opciones que propuso.

  • application/x-javascript: Tipo MIME experimental para JavaScript antes de que application/javascript se hiciera estándar.

  • text/javascript: Ahora obsoleto. Debe usar text/x-javascript cuando use javascript.

  • text/x-json: tipo MIME experimental para la situación anterior.

  • <=>: Tipo MIME experimental para JSON antes de que <=> se registre oficialmente.

En general, siempre que tenga dudas sobre los tipos de contenido, debe marcar este enlace

En JSP , puede usar esto en la directiva de página:

<%@ page language="java" contentType="application/json; charset=UTF-8"
    pageEncoding="UTF-8"%>

El tipo de medio MIME correcto para JSON es application/json. JSP lo usará para enviar una respuesta al cliente.

& # 8220; application/json & # 8221; es el tipo de contenido JSON correcto.

def ajaxFindSystems = {
  def result = Systems.list()
  render(contentType:'application/json') {
    results {
      result.each{sys->
        system(id:sys.id, name:sys.name)
      }
    }
    resultset (rows:result.size())
  }
}

El el registro de IANA para application/json dice

  

Aplicaciones que usan este tipo de medio: JSON se ha usado para      intercambiar datos entre aplicaciones escritas en todos estos      lenguajes de programación: ActionScript, C, C #, Clojure, ColdFusion,      Common Lisp, E, Erlang, Go, Java, JavaScript, Lua, Objective CAML,      Perl, PHP, Python, Rebol, Ruby, Scala y Scheme.

Notará que IANA.org no enumera ninguno de estos otros tipos de medios , de hecho, incluso application/javascript ahora está obsoleto. Entonces text/json es realmente la única respuesta correcta posible.

El soporte del navegador es otra cosa.

Los tipos de medios no estándar más compatibles son text/javascript o text/plain. Pero algunos grandes nombres incluso usan text/xml.

Aún más extraño es el encabezado Content-Type enviado por Flickr, que devuelve JSON como Content-Type: text/javascript. Google usa Content-Type: text/xml para algunos de sus apis ajax.

Ejemplos:

curl -I "https://ajax.googleapis.com/ajax/services/search/video?v=1.0&q=jsonexample"

Salida: <=>

curl -I "https://www.flickr.com/services/rest/?method=flickr.test.echo&format=json&api_key=f82254c1491d894f1204d8408f645a93"

Salida: <=>

El tipo MIME correcto es application/json

BUT

Experimenté muchas situaciones en las que el tipo de navegador o el usuario del framework necesitaban:

text/html

application/javascript

Uso el siguiente

contentType: 'application/json',
data: JSON.stringify(SendData),

El encabezado Tipo de contenido debe establecerse en ' application / json ' al publicar. El servidor que escucha la solicitud debe incluir & Quot; Aceptar = application / json & Quot ;. En Spring MVC puedes hacerlo así:

@RequestMapping(value="location", method = RequestMethod.POST, headers = "Accept=application/json")

Agregue encabezados a la respuesta:

HttpHeaders headers = new HttpHeaders();
headers.add("Content-Type", "application/json");

En Spring tiene un tipo definido: MediaType.APPLICATION_JSON_VALUE que es equivalente a application / json .

  

El application/json funciona muy bien en PHP para almacenar una matriz u objeto   datos.

Uso este código para colocar datos en JSON en Google Cloud Storage (GCS) que se establece visible públicamente :

$context = stream_context_create([
    'gs' => [
        'acl'=>'public-read', 
        'Content-Type' => 'application/json',
    ]
]);

file_put_contents(
    "gs://BUCKETNAME/FILENAME.json", 
    json_encode((object) $array), 
    false, 
    $context
);

Para recuperar los datos es sencillo:

$data = json_decode(file_get_contents("gs://BUCKETNAME/FILENAME.json"));

Si el JSON está con relleno, entonces será application/jsonp. Si el JSON no tiene relleno, será application/json.

Para lidiar con ambos, es una buena práctica usar: 'application / javascript' sin molestar si es con relleno o sin relleno.

Para JSON, estoy usando:

 Content-Type: application/json

Esto se describe en la propuesta 7158 del formato de intercambio de datos JSON del IETF, Sección 1.2: Especificaciones de JSON .

Extending the accepted responses, when you are using JSON in a REST context...

There is a strong argument about using application/x-resource+json and application/x-collection+json when you are representing REST resources and collections.

And if you decide to follow the jsonapi specification, you should use of application/vnd.api+json, as it is documented.

Altough there is not an universal standard, it is clear that the added semantic to the resources being transfered justify a more explicit Content-Type than just application/json.

Following this reasoning, other contexts could justify a more specific Content-Type.

PHP developers use this:

<?php
    header("Content-type: application/json");

    // Do something here...
?>

If you get data from REST API in JSON so you have to use content-type

For JSON data: Content-Type:application/json
For HTML data: Content-Type:text/html,
For XHTML data: Content-Type:application/xhtml+xml,
For XML data: Content-Type:text/xml, application/xml

JSON (JavaScript Object Notation) and JSONP ("JSON with padding") formats seems to be very similar and therefore it might be very confusing which MIME type they should be using. Even though the formats are similar, there are some subtle differences between them.

So whenever in any doubts, I have a very simple approach (which works perfectly fine in most cases), namely, go and check corresponding RFC document.

JSON RFC 4627 (The application/json Media Type for JavaScript Object Notation (JSON)) is a specifications of JSON format. It says in section 6, that the MIME media type for JSON text is

application/json.

JSONP JSONP ("JSON with padding") is handled different way than JSON, in a browser. JSONP is treated as a regular JavaScript script and therefore it should use application/javascript, the current official MIME type for JavaScript. In many cases, however, text/javascript MIME type will work fine too.

Note that text/javascript has been marked as obsolete by RFC 4329 (Scripting Media Types) document and it is recommended to use application/javascript type instead. However, due to legacy reasons, text/javascript is still widely used and it has cross-browser support (which is not always a case with application/javascript MIME type, especially with older browsers).

Content-Type: application/json - json
Content-Type: application/javascript - json-P
Content-Type: application/x-javascript - javascript
Content-Type: text/javascript - javascript BUT obsolete, older IE versions used to use as html attribute.
Content-Type: text/x-javascript - JavaScript Media Types BUT obsolete
Content-Type: text/x-json - json before application/json got officially registered.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top