Quel est le type de contenu JSON correct?

IANA a enregistré le type MIME officiel pour JSON comme application/json .

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

plus de ressources:

• Types De Supports
• Demande de Commentaires 4627
• bluesmoon: JSON a un type

pour JSON:

Content-Type: application/json

pour JSON-P :

Content-Type: application/javascript

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

par exemple, j'utilise Ext GWT et la réponse du serveur doit aller comme text/html mais contient des données JSON.

côté Client, Ext GWT forme 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 cas d'utilisation de application / json type de réponse, le navigateur me suggère de sauvegarder le fichier.

code source côté serveur snippet using 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:

est une donnée générée dynamiquement, selon les paramètres de requête passés dans L'URL.

exemple:

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

Content-Type: application/json

JSON-P:

JSON avec rembourrage. La réponse est donnée JSON, avec une fonction appel enroulé autour d'elle.

exemple:

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

Content-Type: application/javascript

si vous utilisez Ubuntu ou Debian et que vous servez .les fichiers json par Apache, vous pourriez vouloir 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 aidera à le faire facilement. Cependant, avec Ubuntu vous devez éditer le fichier /etc/mime.types et ajouter la ligne

application/json json

puis redémarrez Apache:

sudo service apache2 restart

si vous appelez ASP.NET Services Web côté client vous devez utiliser application/json pour que cela fonctionne. Je crois que c'est la même chose pour les cadres jQuery et Ext .

le bon type de contenu pour JSON est application/json sauf si vous utilisez JSONP , aussi connu sous le nom de JSON avec Padding, qui est en fait JavaScript et donc le bon type de contenu serait application/javascript .

il ne fait aucun doute que application/json est le meilleur MIME type pour une réponse JSON.

mais j'ai eu une certaine expérience où j'ai dû utiliser application/x-javascript en raison de certains problèmes de compression. Mon environnement d'hébergement est l'hébergement partagé avec GoDaddy . Ils ne me permettent pas de changer la configuration du serveur. J'avais ajouté le code suivant à mon fichier web.config pour comprimer 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 ceci, le .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 statiques et dynamiques. mais cela ne comprime pas du tout les réponses JSON.

après quoi j'ai supprimé ce type nouvellement ajouté et ajouté

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

dans les sections des types statique et dynamique, et a modifié le type de réponse dans

.ashx (gestionnaire asynchrone)

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

seulement si vous voulez 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 changer les configurations IIS .

Uniquement lors de l'utilisation de application/json comme le MIME de type I sont les suivantes (en novembre 2011, avec les versions les plus récentes de Chrome, de 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 formater. Si le type MIME est différent, il apparaîtra comme Réponse le contenu".

tout ne fonctionne Pas pour le type de contenu application/json .

si vous utilisez Ext JS Soumettre pour télécharger le fichier, être conscient que la réponse du serveur est analysée par le navigateur pour créer le document pour le <iframe> .

si le serveur utilise JSON pour envoyer l'objet de retour, alors l'en-tête Content-Type doit être défini à text/html afin de dire au navigateur d'insérer le texte inchangé dans le document corps.

Voir l'Ext JS 3.4.0 documentation de l'API .

JSON est un domain-specific language (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 pour les types MIME est bien sûr dicté par le client, donc text/plain peut faire pour le transfert d'octets, mais alors vous pousserez l'interprétation vers le domaine d'application vendeur inutilement - application/json . Est-ce que vous transférez XML via text/plain ?

mais honnêtement, votre choix du type MIME est un conseil pour le client quant à la façon d'interpréter les données- text/plain ou text/HTML (quand ce N'est pas HTML) est comme type erasure - il est aussi peu informatif que faire tous vos objets de type objet dans un langage dactylographié.

aucune exécution de navigateur que je connaisse ne prendra un document JSON et le mettra automatiquement à la disposition de l'exécution sous forme D'objet JavaScript accessible sans intervention, mais si vous travaillez avec un client handicapé, c'est entièrement autre affaire. Mais ce n'est pas toute l'histoire- RESTful les services JSON n'ont souvent pas D'exécution JavaScript, mais cela ne les empêche pas d'utiliser JSON comme un format d'échange de données viable. Si les clients sont aussi infirmes... alors je considérerais peut-être l'injection HTML via un service de Ajax Templier à la place.

Application / JSON!

si vous êtes dans un environnement côté client, une enquête sur le support cross-browser est obligatoire pour une application Web bien supportée.

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 .

la bonne réponse est:

Content-Type: application/json

Comme beaucoup d'autres l'ont mentionné, application/json 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 MIME expérimental pour JavaScript avant application/javascript a été standard.

• text/javascript : maintenant obsolète. Vous devez utiliser application/javascript lorsque 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 que application/json soit officiellement enregistré.

en somme, chaque fois que vous avez des doutes sur les types de contenu, vous devez cocher ce lien

dans JSP , vous pouvez utiliser ceci dans la directive page:

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

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

" application/json " est la bonne JSON type de contenu.

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

Le IANA inscription pour le application/json dit

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

vous remarquerez que IANA.org ne mentionne aucun de ces autres types de médias , en fait même application/javascript est maintenant obsolète. Donc application/json est vraiment la seule réponse possible correct .

le support du navigateur est une autre chose.

les types de supports non standard les plus largement supportés sont text/json ou 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 comme text/xml . Google utilise text/javascript pour certaines de ses API ajax.

exemples:

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

sortie: Content-Type: text/javascript

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

sortie: Content-Type: text/xml

le type MIME droit est application/json

mais

j'ai connu de nombreuses situations où le type de navigateur ou l'utilisateur de cadre nécessaire:

text/html

application/javascript

j'utilise le ci-dessous

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

l'en-tête Content-Type doit être défini à application/json " lors de la publication. Le serveur qui écoute la requête doit inclure" Accept=application / json ". Au printemps MVC vous pouvez le faire comme ceci:

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

ajouter les en-têtes à la réponse:

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

Dans Printemps vous avez un type défini: MediaType.APPLICATION_JSON_VALUE qui est l'équivalent de application/json .

le application/json fonctionne très bien en PHP pour stocker un tableau ou un objet données.

j'utilise ce code pour mettre les données dans JSON sur Google Cloud Storage (GCS) qui est mis publically viewable :

$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 est simple:

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

si le JSON est avec rembourrage alors il sera application/jsonp . Si le JSON est sans rembourrage, alors il sera application/json .

pour traiter avec les deux, il est une bonne pratique d'utiliser: 'application/javascript' sans se soucier que ce soit avec ou sans rembourrage.

pour JSON, j'utilise:

 Content-Type: application/json

ceci est décrit dans la proposition de L'IETF relative au Format D'échange de données JSON 7158, Section 1.2: spécifications de JSON .

les développeurs PHP utilisent ceci:

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

    // Do something here...
?>

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

Il y a un argument fort sur l'utilisation de application/x-resource+json et application/x-collection+json quand vous représentez RESTE des ressources et des collections.

et si vous décidez de suivre la jsonapi spécification, vous devriez utilisation de application/vnd.api+json , comme il est documenté.

Bien qu'il n'existe 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 application/json .