tutorial - Quel est le type de contenu JSON correct?

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

J'utilise ce code pour placer des données au format JSON sur Google Cloud Storage (GCS), qui est défini pour être affiché 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, rien de plus simple:

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

JSON:

La réponse est une donnée générée 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 un rembourrage. La réponse est constituée de données JSON, entourées d’un appel de fonction.

Exemple:

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

Type de contenu: application/javascript

Étendre les réponses acceptées lorsque vous utilisez JSON dans un contexte REST ...

Il existe un argument de poids sur l’utilisation de application/x-resource+json et application/x-collection+json lorsque vous représentez des ressources et des collections REST.

Et si vous décidez de suivre la spécification jsonapi , vous devez utiliser le application/vnd.api+json , tel qu’il est documenté.

Bien qu’il n’existe pas de norme universelle, il est clair que l’ajout de sémantique aux ressources transférées justifie un type de contenu plus explicite que la simple application/json .

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

Au Spring vous avez un type défini: MediaType.APPLICATION_JSON_VALUE qui équivaut à 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 : type MIME expérimental pour JavaScript avant la application/javascript standard de l' application/javascript .

• 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 l' application/json soit officiellement enregistrée.

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

Dans JSP , vous pouvez utiliser cette directive de page:

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

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

J'utilise le ci-dessous

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

JSON est un langage spécifique au domaine (DSL) et un format de données indépendant de JavaScript. En tant que tel, il possède son propre type MIME , application/json . Le respect des types MIME est bien sûr axé sur le client. Par conséquent, text/plain peut servir à transférer des octets, mais vous risqueriez alors de pousser inutilement l'interprétation vers le domaine d'application du fournisseur - application/json . Souhaitez-vous transférer XML via text/plain ?

Mais honnêtement, votre choix du type MIME indique au client comment interpréter les données - text/plain ou text/HTML (quand ce n'est pas du HTML), c'est comme effacer du type - c'est aussi peu informatif que de créer tous vos objets de type Object dans une langue dactylographiée.

Je ne connais aucun runtime de navigateur prenant un document JSON et le mettant automatiquement à la disposition du runtime en tant qu'objet accessible par JavaScript sans intervention, mais si vous travaillez avec un client estropié, il en va tout autrement. Mais ce n'est pas toute l'histoire - RESTful services JET 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 paralysés ... alors je considérerais peut-être une injection HTML via un service de templates Ajax .

Application / JSON!

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 " Accepter = application / json ". Au printemps MVC, vous pouvez le faire comme ceci:

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

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

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

La bonne réponse est:

Content-Type: application/json

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

Les développeurs PHP utilisent ceci:

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

    // Do something here...
?>

Pour JSON, j'utilise:

 Content-Type: application/json

Ceci est décrit dans la proposition de la section 1.2: Spécifications du format JSON de la norme JSON Data Interchange Format 7158 de l'IETF.

Pour le texte JSON:

application/json

Le type de support MIME pour le texte JSON est application/json . Le codage par défaut est UTF-8. (Source: RFC 4627 ).

Pour JSONP (javascript JSONP ) avec rappel:

application/javascript

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

• Pourquoi vous ne devriez pas utiliser text/html for JSON
• Internet Explorer a parfois des problèmes avec application/json (DEAD 2018-06-26)
• Une liste assez complète de Mimetypes et de quoi les utiliser pour
• La liste officielle des types de mime sur l'IANA de la réponse de @ gnrfan ci-dessous

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

Si vous obtenez des données de l'API REST en JSON, vous devez 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

Si vous vous trouvez dans un environnement côté client, il est indispensable de mener une enquête sur la prise en charge multi-navigateurs pour une application Web bien prise en charge.

Le bon type de contenu HTTP serait application/json , comme d’autres déjà mis en évidence, mais certains clients ne le gèrent pas très bien, c’est pourquoi jQuery recommande le text/html par défaut.

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

Si vous utilisez la soumission de formulaire Ext JS 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 <iframe> .

Si le serveur utilise JSON pour envoyer l'objet de retour, l'en Content-Type tête Content-Type doit être défini sur text/html afin d'indiquer au navigateur d'insérer le texte sans modification dans le corps du document.

Voir la documentation de l'API Ext JS 3.4.0 .

JSON formats JSON (JavaScript Object Notation) et JSONP ("JSON avec padding") semblent très similaires et par conséquent, le type MIME à utiliser peut être très déroutant. Même si les formats semblent très similaires, il existe de subtiles différences entre eux.

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

JSON RFC 4627 (Le type de support application / json pour la notation d'objet JavaScript (JSON)) est une spécification du format JSON. Dans la section 6, il est indiqué que le type de support MIME pour le texte JSON est

application/json.

JSONP JSONP ("JSON avec remplissage") est traité 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 type MIME text/javascript fonctionnera également.

Notez que text/javascript a été marqué comme obsolète par le document rfc-editor.org/rfc/rfc4329.txt (Scripting Media Types) et qu'il est recommandé d'utiliser le type application/javascript . Cependant, pour des raisons héritées, text/javascript est encore largement utilisé et prend en charge plusieurs navigateurs (ce qui n’est pas toujours le cas avec le type MIME application/javascript , en particulier avec les anciens navigateurs).

Content-type: application/json - json
Content-Type: application/javascript - json-p
Content-type: application/x-javascript - javascript
Content-type: text/javascript - javascript MAIS obsolète, les anciennes versions d'Internet Explorer étaient utilisées comme attribut HTML.
Content-type: text/x-javascript - Types de support JavaScript MAIS obsolète
Content-type: text/x-json - json avant que l'application / json ne soit officiellement enregistrée.