Quel est le type de contenu JSON correct?


10257

Je joue avec JSON depuis un certain temps, je l'ai simplement mis sous forme de texte et cela n'a fait de mal à personne (à ma connaissance), mais j'aimerais commencer à faire les choses correctement.

J'ai vu tant de prétendues «normes» pour le type de contenu JSON:

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

Mais lequel est correct, ou le meilleur? Je suppose qu'il existe des problèmes de sécurité et de prise en charge du navigateur variant entre eux.

Je sais qu'il y a une question similaire, quel type MIME si JSON est retourné par une API REST? , mais j'aimerais une réponse un peu plus ciblée.

Réponses:


10311

Pour le texte JSON:

application/json

Le type de média MIME pour le texte JSON est application/json. L'encodage par défaut est UTF-8. (Source: RFC 4627 ).

Pour JSONP (javascript exécutable ) avec rappel:

application/javascript

Voici quelques articles de blog mentionnés dans les commentaires qui sont pertinents.



Puis-je envoyer un fichier ensemble avec du texte Json?
OPV

7
Internet Explorer a parfois des problèmes avec application / json - le blog est hors ligne
kudlatiger

6
Imaginez que j'ai un document écrit par quelqu'un qui contient du texte brut. Maintenant, ce texte brut se trouve être également du JSON valide. Serais-je alors dans l'erreur d'utiliser text / plain comme type mime? JSON est un sous-type de texte. Je pense donc que les deux devraient être autorisés. La question est de savoir qui fonctionne mieux dans la pratique. Selon les commentaires de codetoshare, IE a des problèmes avec application / json. Mais aucun navigateur ne devrait avoir de problèmes avec text / plain. Si text / plain est dangereux, comment puis-je servir des fichiers texte à partir de mon site Web?
Panu Logic

5
@EugenMihailescu Le titre de cette page est "Liste incomplète des types MIME"
Omegastick

1617

L'IANA a enregistré le type MIME officiel pour JSON en tant que application/json.

Lorsqu'on lui a demandé pourquoi text/json, Crockford semble avoir dit que JSON n'est pas vraiment du JavaScript ni du texte et que l'IANA était plus susceptible de distribuer application/*que text/*.

Davantage de ressources:


166
Beaucoup de choses ont été mises dans la text/*section dans les premiers jours qui seraient probablement mises dans la application/*section ces jours-ci.
TRiG

29
@Rohmer - Vous "pouvez" ouvrir n'importe quoi dans un éditeur de texte, mais un format binaire comme JPEG ou Windows .exe ou .zip contiendra des caractères non imprimables qui peuvent en fait casser de nombreux éditeurs de texte ou provoquer un comportement indésirable. Essayez de courir cat file.jpgpar exemple. Alors que tout fichier xml ou json est 100% imprimable. Je pense donc que le point de Stijn de Witt est valable, malgré le fait qu'il est trop tard pour changer maintenant.
XP84

4
@ XP84 Vous pouvez ouvrir n'importe quel binaire avec un éditeur de texte sous forme HEX. Et tous les différents personnages (les 16 d'entre eux) sont 100% imprimables. Donc, par cette logique ... tous les binaires sont-ils du texte? Json n'est pas du texte. Json est (avertissement: définition lâche informelle à venir) une représentation textuelle d'un objet (ou d'un tableau d'objets)
xDaizu

5
Il n'y a aucune signification à l'expression "un éditeur de texte sous forme HEX". Un éditeur hexadécimal affiche chaque octet comme sa valeur hexadécimale, par exemple, l'octet 1111000 comme "78". Bien qu'il puisse y avoir certains éditeurs de texte qui ont également un mode d'édition hexadécimal, ce n'est ni courant ni utile pour autre chose que les utilisateurs les plus techniques effectuant les tâches les plus techniques. Le texte, par comparaison, signifie ASCII ou Unicode, et dans le texte, l'octet 1111000 signifie un xcaractère en minuscule . Pas 78. JSON est du texte exactement de la même manière que HTML (text / html). Il ne contient que des caractères de texte lisibles, avec une signification structurée.
XP84

11
J'ai tendance à être d'accord avec Stijn de Witt. JSON est destiné à être visualisé et édité avec un éditeur de texte.
Panu Logic

891

Pour JSON:

Content-Type: application/json

Pour JSON-P :

Content-Type: application/javascript

62
JSONP n'est cependant pas vraiment JSON, c'est une technique pour passer un objet JavaScript littéral
Benjamin Gruenbaum

632

Bien sûr, le type de média MIME correct pour JSON est application/json, mais il est nécessaire de savoir quel type de données est attendu dans votre application.

Par exemple, j'utilise Ext GWT et la réponse du serveur doit aller en tant que texte / html mais contient des données JSON.

Côté client, écouteur de formulaire 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");
    }
});

En cas d'utilisation du type de réponse application / json , le navigateur me propose de sauvegarder le fichier.

Extrait de code source côté serveur utilisant 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);
    }
};

7
la réponse du serveur doit aller en texte / html. Cela est également vrai pour la variante ExtJS.
gbegley

463

JSON:

La réponse est des données générées dynamiquement, en fonction des paramètres de requête transmis dans l'URL.

Exemple:

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

Type de contenu: application/json


JSON-P:

JSON avec rembourrage. La réponse est des données JSON, avec un appel de fonction enroulé autour.

Exemple:

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

Type de contenu: application/javascript


46
La définition de JSON est incorrecte. Il n'a pas besoin d'être généré dynamiquement ni de respecter les paramètres de requête. Vous pouvez servir un fichier JSON statique. En outre, la réponse la plus votée a un lien vers le RFC.
styfle

10
JSONP peut également être des données json affectées à une var.
Jimmy Kane

401

Si vous utilisez Ubuntu ou Debian et que vous servez des fichiers .json via Apache, vous souhaiterez peut-être servir les fichiers avec le type de contenu correct. Je le fais principalement parce que je veux utiliser l'extension Firefox JSONView

Le module Apache mod_mime vous aidera à le faire facilement. Cependant, avec Ubuntu, vous devez modifier le fichier /etc/mime.types et ajouter la ligne

application/json json

Redémarrez ensuite Apache:

sudo service apache2 restart

44
un rechargement est généralement suffisant (plus rapide qu'un redémarrage). Notez également que vous pouvez désormais effectuer "sudo service apache2 reload".
noamtm

19
Ubuntu 12.04 a cela par défaut
Prizoff

386

Si vous appelez les services Web ASP.NET du côté client, vous devez l'utiliser application/jsonpour que cela fonctionne. Je pense que c'est la même chose pour les frameworks jQuery et Ext .


20
jQuery semble fonctionner avec au moins 'application / json' et 'text / plain' ... Je n'ai pas essayé tous les autres cependant.
Nathan

jQuery est capable de travailler avec content-Type: text/plain, content-Type: application/json, content-Type: application/json; charset=UTF-8, contentType: "application/x-www-form-urlencoded; charset=UTF-8"
Ashraf.Shk786

307

Le bon type de contenu pour JSON est À application/jsonMOINS QUE vous n'utilisiez JSONP , également connu sous le nom de JSON avec remplissage, qui est en fait JavaScript et donc le bon type de contenu serait application/javascript.


296

Il ne fait aucun doute que application/jsonc'est le meilleur type MIME pour une réponse JSON.

Mais j'avais une certaine expérience où je devais utiliser à application/x-javascriptcause de certains problèmes de compression. Mon environnement d'hébergement est l'hébergement partagé avec GoDaddy . Ils ne me permettent pas de modifier les configurations de serveur. J'avais ajouté le code suivant à mon web.configfichier pour compresser les réponses.

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

En utilisant cela, les pages .aspx ont été compressées avec g-zip, mais pas les réponses JSON. J'ai ajouté

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

dans les sections types statique et dynamique. Mais cela ne compresse pas du tout les réponses JSON.

Après cela, j'ai supprimé ce type nouvellement ajouté et ajouté

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

dans les sections des types statiques et dynamiques et a changé le type de réponse dans

.ashx (gestionnaire asynchrone) vers

application/x-javascript

Et maintenant, j'ai trouvé que mes réponses JSON étaient compressées avec g-zip. Je recommande donc personnellement d'utiliser

application/x-javascript

uniquement si vous souhaitez compresser vos réponses JSON sur un environnement d'hébergement partagé . Parce que dans l'hébergement partagé, ils ne vous permettent pas de modifier les configurations IIS .


11
"Donc, je recommande personnellement d'utiliser application / x-javascript", c'est là que cette réponse devient trompeuse. GoDaddy ne permet la compression application/json, je l' effet de levier sur mon hébergement mutualisé et je ne suggère d' utiliser un type de contenu différent pour activer la compression de toute façon, il est tout simplement faux. Cela peut être fait, mais ce sera toujours faux. L'utilisation de différents types de contenu pour la prise en charge du navigateur est une chose, l'utilisation de différents types de contenu pour la compression côté serveur en est une autre.

269

Seulement lors de l' utilisation en application/jsontant que MIME type I donne les résultats suivants (en date de Novembre 2011 avec les versions les plus récentes de Chrome, Firefox avec Firebug ):

  • Plus d'avertissements de Chrome lorsque le JSON est chargé à partir du serveur.
  • Firebug ajoutera un onglet à la réponse vous montrant les données JSON formatées. Si le type MIME est différent, il apparaîtra simplement comme «Contenu de réponse».

244

Tout ne fonctionne pas pour le type de contenu application/json.

Si vous utilisez le formulaire Ext JS soumettre pour télécharger le fichier, sachez que la réponse du serveur est analysée par le navigateur pour créer le document pour le fichier <iframe>.

Si le serveur utilise JSON pour envoyer l'objet de retour, l'en- Content-Typetête doit être défini sur text/htmlafin de dire au navigateur d'insérer le texte inchangé dans le corps du document.

Voir la documentation de l'API Ext JS 3.4.0 .


40
Les outils qui ne respectent pas les normes doivent être évités autant que possible; utiliser application/jsonpar spec.
one.beat.consumer

15
@ one.beat.consumer bien que cela soit vrai, ce n'est pas spécifique aux ExtJ en soi. C'est une limitation du navigateur (ou plutôt, peut-être, une "mesure de sécurité").
Hendy Irawan

7
Il serait sûrement préférable d'utiliser text / plain afin qu'il n'applique aucune sémantique HTML au contenu non HTML? Ou les navigateurs ne vous permettent-ils pas d'extraire le contenu d'un cadre s'il n'a pas de DOM?
Synchro

5
Pour ajouter à la confusion: Je débogage juste un cas similaire sur Samsung Galaxy Beam (Android 2.3) avec le navigateur par défaut, et iframesemble le feu loadévénement pour application/javascript, application/x-javascript, text/javascript, text/plain, mais pas de tir pour application/jsonni text/html. À ce jour, Android <= 2,3 représente environ 50% de la part de marché d'Android.
jakub.g

226

JSON est un langage spécifique à domaine (DSL) et un format de données indépendant de JavaScript, et en tant que tel a son propre MIME type application/json. Le respect des types MIME est bien sûr axé sur le client, il text/plainpeut en être de même pour le transfert d'octets, mais alors vous pousseriez inutilement l'interprétation vers le domaine d'application du fournisseur - application/json. Transféreriez-vous XML via text/plain?

Mais honnêtement, votre choix de type MIME est un conseil au client sur la façon d'interpréter les données - text/plainou text/HTML(quand ce n'est pas HTML) est comme l'effacement de type - c'est aussi peu informatif que de faire tous vos objets de type Object dans un langage typé.

Aucun runtime de navigateur que je connais ne prendra un document JSON et le mettra automatiquement à la disposition du runtime en tant qu'objet accessible en JavaScript sans intervention, mais si vous travaillez avec un client handicapé, c'est une tout autre affaire. Mais ce n'est pas toute l'histoire: les services JSON RESTful n'ont souvent pas d'exécution JavaScript, mais cela ne les empêche pas d'utiliser JSON comme format d'échange de données viable. Si les clients sont aussi paralysés ... alors je considérerais peut-être plutôt l' injection HTML via un service de modèle Ajax .

Application / JSON!


210

Si vous êtes dans un environnement côté client, une enquête sur la prise en charge de plusieurs navigateurs est obligatoire pour une application Web bien prise en charge.

Le bon type de contenu HTTP serait application/json, comme d'autres l'ont déjà souligné, mais certains clients ne le gèrent pas très bien, c'est pourquoi jQuery recommande la valeur par défaut text/html.



166

Comme beaucoup d'autres l'ont mentionné, application/jsonc'est la bonne réponse.

Mais ce qui n'a pas encore été expliqué, c'est ce que signifient les autres options que vous avez proposées.

  • application/x-javascript: Le type expérimental MIME pour JavaScript application/javascriptétait devenu standard.

  • text/javascript: Désormais obsolète. Vous devez utiliser application/javascriptlorsque vous utilisez javascript.

  • text/x-javascript: Type MIME expérimental pour la situation ci-dessus.

  • text/x-json: Type MIME expérimental pour JSON avant d' application/jsonêtre officiellement enregistré.

Dans l'ensemble, chaque fois que vous avez des doutes sur les types de contenu, vous devriez vérifier ce lien


15
Quand est text/javascriptdevenu obsolète? Je remplis toujours des documents HTML avec des <script type="text/javascript" ...balises.
Oli

7
Cela ne fait vraiment aucune différence pour les navigateurs. C'est juste obsolète pour les normes RFC: rfc-editor.org/rfc/rfc4329.txt
fcm

16
@Oli, vous pouvez déposer en toute sécurité type="text/javascript"et faire <script>...</script>au moins selon HTML5.
TCB13

149

Dans JSP , vous pouvez utiliser cette directive dans la page:

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

Le type de média MIME correct pour JSON est application/json. JSP l'utilisera pour envoyer une réponse au client.


115

" application/json" Est le type de contenu JSON correct.

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

112

L' enregistrement IANA pourapplication/json dit

Applications utilisant ce type de média: JSON a été utilisé pour échanger des données entre des applications écrites dans tous ces langages de programmation: ActionScript, C, C #, Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript, Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala et Scheme.

Vous remarquerez que IANA.org ne répertorie aucun de ces autres types de médias , en fait même application/javascriptest désormais obsolète. C'est donc application/jsonvraiment la seule bonne réponse possible .

La prise en charge du navigateur est une autre chose.

Les types de supports non standard les plus largement pris en charge sont text/jsonou text/javascript. Mais certains grands noms utilisent même text/plain.

Encore plus étrange est l'en-tête Content-Type envoyé par Flickr, qui renvoie JSON sous text/xml. Google utilise text/javascriptpour certains de ses apis ajax.

Exemples:

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

Production: Content-Type: text/javascript

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

Production: Content-Type: text/xml


90

Le bon type MIME est application/json

MAIS

J'ai vécu de nombreuses situations où le type de navigateur ou l'utilisateur du framework avait besoin:

text/html

application/javascript

10
Exemple d'une telle situation?
Mark Amery

75

J'utilise le ci-dessous

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

66

L'en - tête Content-Type doit être défini sur « application / json » lors de la publication. Le serveur qui écoute la demande doit inclure " Accept = application / json ". Dans Spring MVC, vous pouvez le faire comme ceci:

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

Ajoutez des en-têtes à la réponse:

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


59

Cela application/jsonfonctionne très bien en PHP pour stocker un tableau ou des données d'objet.

J'utilise ce code pour mettre des données en JSON sur Google Cloud Storage (GCS) qui est défini publiquement :

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

Pour récupérer les données, c'est simple:

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

50

Si le JSON est avec un remplissage, il le sera application/jsonp. Si le JSON est sans remplissage, il le sera application/json.

Pour gérer les deux, c'est une bonne pratique d'utiliser: 'application / javascript' sans se soucier que ce soit avec ou sans remplissage.


8
La première partie de votre réponse est fausse. "application / jsonp" n'est pas un type MIME valide. Le corps de réponse d'un JSONP est juste JavaScript, donc l'un des types MIME pour JavaScript doit être utilisé.
Rob W


43

Extension des réponses acceptées, lorsque vous utilisez JSON dans un contexte REST ...

Il existe un argument solide sur l'utilisation application/x-resource+jsonet le application/x-collection+jsonmoment où vous représentez les ressources et les collections REST.

Et si vous décidez de suivre la spécification jsonapi , vous devez utiliser application/vnd.api+json, car elle est documentée.

Bien qu'il n'y ait pas de norme universelle, il est clair que la sémantique ajoutée aux ressources transférées justifie un type de contenu plus explicite que juste application/json.

Suivant ce raisonnement, d'autres contextes pourraient justifier un type de contenu plus spécifique .


3
application/vnd.api+jsonsemble être spécifiquement pour les API utilisant json: api , une spécification très étroite avec ses propres attentes et format, je ne comprends pas que ce soit pour une API qui renvoie json. Veuillez me corriger si je me trompe
Hilikus

42

Les développeurs PHP utilisent ceci:

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

    // Do something here...
?>

39

Si vous obtenez des données de l'API REST en JSON, vous devez donc utiliser le type de contenu

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

28

Content-Type: application/json- json
Content-Type: application/javascript- json-P
Content-Type: application/x-javascript- javascript
Content-Type: text/javascript- javascript MAIS obsolètes, les anciennes versions d'IE utilisées comme attribut html.
Content-Type: text/x-javascript- Types de supports JavaScript MAIS obsolètes
Content-Type: text/x-json- json avant l'application / json a été officiellement enregistré.


Pour le texte JSON: application / json Content-Type: application / json
Vikash Chauhan

28

Les formats JSON (JavaScript Object Notation) et JSONP ("JSON with padding") semblent être très similaires et il peut donc être très déroutant de savoir quel type MIME ils devraient utiliser. Même si les formats sont similaires, il existe de subtiles différences entre eux.

Donc, en cas de doute, j'ai une approche très simple (qui fonctionne parfaitement bien dans la plupart des cas), à savoir aller vérifier le document RFC correspondant.

JSON RFC 4627 (le type de média application / json pour la notation d'objet JavaScript (JSON)) est une spécification du format JSON. Il est dit dans la section 6, que le type de média MIME pour le texte JSON est

application/json.

JSONP JSONP ("JSON avec remplissage") est géré différemment de JSON, dans un navigateur. JSONP est traité comme un script JavaScript standard et doit donc utiliser application/javascript,le type MIME officiel actuel pour JavaScript. Dans de nombreux cas, cependant, le text/javascripttype MIME fonctionnera également très bien.

Notez que cela text/javascripta été marqué comme obsolète par le document RFC 4329 (Scripting Media Types) et il est recommandé d'utiliser application/javascriptplutôt le type. Cependant, pour des raisons héritées, il text/javascriptest toujours largement utilisé et il prend en charge plusieurs navigateurs (ce qui n'est pas toujours le cas avec le application/javascripttype MIME, en particulier avec les navigateurs plus anciens).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.