Qual è il tipo di contenuto JSON corretto?

Sto scherzando con JSON da un po 'di tempo, lo sto solo spingendo come testo e non ha fatto male a nessuno (che io conosca), ma mi piacerebbe iniziare a fare le cose nel modo giusto.

Ho visto così tanti presunti "standard" per il tipo di contenuto JSON:

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

Ma quale è corretto o migliore? Accetto che ci sono problemi di sicurezza e supporto del browser che variano tra di loro.

So che c'è una domanda simile, che tipo MIME se JSON viene restituito da un'API REST? , ma vorrei una risposta leggermente più mirata.

Per il testo JSON:

application/json

Il tipo di supporto MIME per il testo JSON è application/json. La codifica predefinita è UTF-8. (Fonte: RFC 4627 ).

Per JSONP (javascript eseguibile) con callback:

application/javascript

Ecco alcuni post di blog che sono stati menzionati nei commenti che sono rilevanti.

• Perché non dovresti usare text/htmlper JSON
• Internet Explorer a volte ha problemi con application/json
• Un elenco piuttosto completo di Mimetypes e per cosa utilizzarli
• L'elenco ufficiale dei tipi di mime su IANA dalla risposta di @ gnrfan di seguito

IANA ha registrato il tipo MIME ufficiale per JSON come application/json.

Alla domanda sul perché no text/json, sembra che Crockford abbia detto che JSON non è in realtà JavaScript né testo e che anche IANA ha più probabilità di distribuirlo application/*di text/*.

Altre risorse:

• Tipi di media
• Richiesta di commenti 4627
• bluesmoon: JSON ha un tipo

Per JSON:

Content-Type: application/json

Per JSON-P :

Content-Type: application/javascript

Naturalmente, il tipo di supporto MIME corretto per JSON è application/json , ma è necessario rendersi conto del tipo di dati previsto nell'applicazione.

Ad esempio, utilizzo Ext GWT e la risposta del server deve andare come text / html ma contiene dati JSON.

Lato client, listener di moduli Ext GWT

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");
    }
});

In caso di utilizzo di application / json tipo di risposta , il browser mi suggerisce di salvare il file.

Snippet di codice sorgente lato server utilizzando 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 risposta è un dato generato dinamicamente, in base ai parametri della query passati nell'URL.

Esempio:

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

Tipo di contenuto: application/json

JSON-P:

JSON con imbottitura. La risposta sono dati JSON, con una chiamata di funzione racchiusa intorno.

Esempio:

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

Tipo di contenuto: application/javascript

Se stai usando Ubuntu o Debian e servi file .json tramite Apache, potresti voler servire i file con il tipo di contenuto corretto. Lo sto facendo principalmente perché voglio usare l'estensione JSONView di Firefox

Il modulo Apache mod_mime ti aiuterà a farlo facilmente. Tuttavia, con Ubuntu è necessario modificare il file /etc/mime.types e aggiungere la riga

application/json json

Quindi riavviare Apache:

sudo service apache2 restart

Se si chiama ASP.NET Web Services dal lato client, è necessario utilizzarlo application/jsonaffinché funzioni. Credo che sia lo stesso per i framework jQuery ed Ext .

Il giusto tipo di contenuto per JSON è A application/jsonMENO CHE non si stia utilizzando JSONP , noto anche come JSON con Padding, che in realtà è JavaScript e quindi sarebbe il giusto tipo di contenuto application/javascript.

Non c'è dubbio che application/jsonsia il miglior tipo MIME per una risposta JSON.

Ma ho avuto qualche esperienza in cui ho dovuto usare a application/x-javascriptcausa di alcuni problemi di compressione. Il mio ambiente di hosting è hosting condiviso con GoDaddy . Non mi consentono di modificare le configurazioni del server. Avevo aggiunto il seguente codice al mio web.configfile per comprimere le risposte.

<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"/>

Usando questo, le pagine .aspx sono state compresse con g-zip ma le risposte JSON no. Ho aggiunto

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

nelle sezioni dei tipi statici e dinamici. Ma questo non comprime affatto le risposte JSON.

Dopo di che ho rimosso questo tipo appena aggiunto e aggiunto

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

in entrambe le sezioni dei tipi statici e dinamici e modificato il tipo di risposta in

.ashx (gestore asincrono) in

application/x-javascript

E ora ho scoperto che le mie risposte JSON erano compresse con g-zip. Quindi raccomando personalmente di usare

application/x-javascript

solo se vuoi comprimere le tue risposte JSON su un ambiente di hosting condiviso . Perché nell'hosting condiviso, non consentono di modificare le configurazioni IIS .

Solo quando utilizzo application/jsoncome tipo MIME ho i seguenti (a partire da novembre 2011 con le versioni più recenti di Chrome, Firefox con Firebug ):

• Non più avvisi da Chrome quando JSON viene caricato dal server.
• Firebug aggiungerà una scheda alla risposta che mostra i dati JSON formattati. Se il tipo MIME è diverso, verrà visualizzato solo come "Contenuto della risposta".

Non tutto funziona per il tipo di contenuto application/json.

Se si utilizza il modulo Ext JS per l'invio del file di caricamento, tenere presente che la risposta del server viene analizzata dal browser per creare il documento per il file <iframe>.

Se il server utilizza JSON per inviare l'oggetto di ritorno, è Content-Typenecessario impostare l' intestazione su text/htmlper indicare al browser di inserire il testo invariato nel corpo del documento.

Vedere la documentazione dell'API Ext JS 3.4.0 .

JSON è un linguaggio di dominio-specifici (DSL) e un formato di dati indipendente da JavaScript, e come tale ha il suo MIME tipo, application/json. Il rispetto per i tipi MIME è ovviamente guidato dal client, quindi text/plainpuò essere utile per il trasferimento di byte, ma in tal caso si spingerebbe inutilmente verso l'interpretazione nel dominio dell'applicazione del fornitore - application/json. Trasferiresti XML via text/plain?

Ma onestamente, la scelta del tipo MIME è una consulenza al cliente su come interpretare i dati - text/plaino text/HTML(quando non è HTML) è come la cancellazione del tipo - è disinformativa come rendere tutti i tuoi oggetti di tipo Oggetto in un linguaggio tipizzato.

Nessun runtime del browser che conosco prenderà un documento JSON e lo renderà automaticamente disponibile al runtime come oggetto accessibile JavaScript senza intervento, ma se stai lavorando con un client paralizzato, è una faccenda completamente diversa. Ma non è tutta la storia: i servizi JSON RESTful spesso non hanno runtime JavaScript, ma non li impediscono di utilizzare JSON come formato di scambio di dati praticabile. Se i clienti sono così paralizzati ... prenderei in considerazione forse l'iniezione HTML tramite un servizio di template Ajax .

Applicazione / JSON!

Se ti trovi in ​​un ambiente lato client, è necessario indagare sul supporto cross-browser per un'applicazione Web ben supportata.

Il giusto tipo di contenuto HTTP sarebbe application/json, come già evidenziato da altri, ma alcuni client non lo gestiscono molto bene, ecco perché jQuery consiglia l'impostazione predefinita text/html.

La risposta corretta è:

Content-Type: application/json

Come molti altri hanno già detto, application/jsonè la risposta corretta.

Ma ciò che non è stato ancora spiegato è ciò che significano le altre opzioni che hai proposto.

• application/x-javascript: Il tipo MIME sperimentale per JavaScript prima application/javascriptera stato reso standard.

• text/javascript: Ora obsoleto. Dovresti usare application/javascriptquando usi javascript.

• text/x-javascript: Tipo MIME sperimentale per la situazione precedente.

• text/x-json: Il tipo MIME sperimentale per JSON prima di application/jsonessere ufficialmente registrato.

Tutto sommato, ogni volta che hai dei dubbi sui tipi di contenuto, dovresti controllare questo link

In JSP , puoi usare questo nella direttiva della pagina:

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

Il tipo di supporto MIME corretto per JSON è application/json. JSP lo utilizzerà per inviare una risposta al client.

" application/json" È il tipo di contenuto JSON corretto.

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())
  }
}

La registrazione IANA perapplication/json dice

Applicazioni che utilizzano questo tipo di supporto: JSON è stato utilizzato per scambiare dati tra applicazioni scritte in tutti questi linguaggi di programmazione: ActionScript, C, C #, Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript, Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala e Scheme.

Noterai che IANA.org non elenca nessuno di questi altri tipi di media , infatti application/javascriptè addirittura obsoleto. Quindi application/jsonè davvero l'unica possibile risposta corretta .

Il supporto del browser è un'altra cosa.

I tipi di supporto non standard più ampiamente supportati sono text/jsono text/javascript. Ma usano anche alcuni grandi nomi text/plain.

Ancora più strano è l'intestazione Content-Type inviata da Flickr, che restituisce JSON come text/xml. Google utilizza text/javascriptper alcune delle sue API Ajax.

Esempi:

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

Produzione: Content-Type: text/javascript

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

Produzione: Content-Type: text/xml

Il giusto tipo MIME è application/json

MA

Ho riscontrato molte situazioni in cui era necessario il tipo di browser o l'utente del framework:

text/html

application/javascript

Uso il seguito

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

L' intestazione Content-Type deve essere impostata su " application / json " durante la pubblicazione. Il server in ascolto per la richiesta dovrebbe includere " Accept = application / json ". In Spring MVC puoi farlo in questo modo:

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

Aggiungi intestazioni alla risposta:

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

In primavera hai un tipo definito: MediaType.APPLICATION_JSON_VALUEche equivale a application / json .

Le application/jsonopere grandi in PHP per memorizzare una matrice o oggetto dati.

Uso questo codice per inserire dati in JSON su Google Cloud Storage (GCS) che è pubblicamente impostato :

$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
);

Per recuperare i dati è semplice:

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

Se il JSON è con imbottitura, lo sarà application/jsonp. Se il JSON è senza riempimento, lo sarà application/json.

Per gestire entrambi, è una buona pratica usare: 'application / javascript' senza preoccuparsi che si tratti di padding o senza padding.

Per JSON, sto usando:

 Content-Type: application/json

Questo è descritto nella proposta IETF JSON Data Interchange Format 7158, Sezione 1.2: Specifiche di JSON .

Estensione delle risposte accettate, quando si utilizza JSON in un contesto REST ...

Vi è una forte argomentazione sull'uso application/x-resource+jsone sulla application/x-collection+jsonrappresentazione delle risorse e delle raccolte REST.

E se decidi di seguire le specifiche jsonapi , dovresti utilizzareapplication/vnd.api+json , come è documentato.

Sebbene non esista uno standard universale, è chiaro che la semantica aggiunta alle risorse trasferite giustifica un tipo di contenuto più esplicito di un sempliceapplication/json .

Seguendo questo ragionamento, altri contesti potrebbero giustificare un tipo di contenuto più specifico .

Gli sviluppatori PHP usano questo:

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

    // Do something here...
?>

Se si ottengono dati dall'API REST in JSON, è necessario utilizzare il tipo di contenuto

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

Content-Type: application/json- json
Content-Type: application/javascript- json-P
Content-Type: application/x-javascript- javascript
Content-Type: text/javascript- javascript MA versioni obsolete e precedenti di IE utilizzate come attributo html.
Content-Type: text/x-javascript- Tipi di media JavaScript MA obsoleti
Content-Type: text/x-json- json prima che application / json venisse ufficialmente registrato.

I formati JSON (JavaScript Object Notation) e JSONP ("JSON with padding") sembrano essere molto simili e quindi potrebbero confondere il tipo MIME che dovrebbero usare. Anche se i formati sono simili, ci sono alcune sottili differenze tra loro.

Quindi ogni volta che ho dei dubbi, ho un approccio molto semplice (che funziona perfettamente bene nella maggior parte dei casi), vale a dire, andare a controllare il documento RFC corrispondente.

JSON RFC 4627 (il tipo di supporto application / json per JavaScript Object Notation (JSON)) è una specifica del formato JSON. Nella sezione 6 si dice che il tipo di supporto MIME per il testo JSON è

application/json.

JSONP JSONP ("JSON con imbottitura") è gestito in modo diverso rispetto a JSON, in un browser. JSONP è trattato come un normale script JavaScript e pertanto dovrebbe utilizzare application/javascript,l'attuale tipo MIME ufficiale per JavaScript. In molti casi, tuttavia, anche il text/javascripttipo MIME funzionerà bene.

Si noti che text/javascriptè stato contrassegnato come obsoleto dal documento RFC 4329 (Tipi di supporti di scripting) e si consiglia di utilizzare application/javascriptinvece il tipo. Tuttavia, per motivi legacy, text/javascriptè ancora ampiamente utilizzato e ha il supporto cross-browser (che non è sempre un caso con il application/javascripttipo MIME, specialmente con i browser più vecchi).