Quelle est la différence entre text / xml vs application / xml pour la réponse webservice

Ceci est plus une question générale sur la différence entre text/xml et application/xml . Je suis assez nouveau pour écrire des services web (REST – Jersey). J’ai produit application/xml car c’est ce qui apparaît dans la plupart des exemples de didacticiels / codes que j’ai utilisé pour apprendre, mais j’ai récemment découvert text/xml et je me demandais ce qui était différent et quand l’utiliseriez-vous? sur application/xml ?

A partir de la RFC ( 3023 ), section 3, Types de média XML:

Si un document XML – c’est-à-dire le document XML source non traité – est lisible par des utilisateurs occasionnels, text / xml est préférable à application / xml. Les agents utilisateurs MIME (et agents utilisateurs Web) qui ne prennent pas explicitement en charge text / xml le traiteront comme du texte / plaine, par exemple en affichant l’entité XML MIME en texte brut. Application / xml est préférable lorsque l’entité XML MIME est illisible par des utilisateurs occasionnels.

(emphase le mien)

Ceci est une vieille question, mais celle qui est fréquemment visitée et des recommandations claires sont maintenant disponibles à partir de la RFC7303 qui rend obsolète la RFC3023. En bref (section 9.2):

 The registration information for text/xml is in all respects the same as that given for application/xml above (Section 9.1), except that the "Type name" is "text". 

Selon cet article, l’ application / xml est préférée.


MODIFIER

J’ai fait un peu de suivi sur l’article.

L’auteur affirme que le codage déclaré dans les instructions de traitement XML, comme:

  

peut être ignoré lorsque le type de support text/xml est utilisé.

Ils soutiennent la thèse avec la définition de la spécification de famille de type text/* MIME dans la RFC 2046 , en particulier le fragment suivant:

 4.1.2. Charset Parameter A critical parameter that may be specified in the Content-Type field for "text/plain" data is the character set. This is specified with a "charset" parameter, as in: Content-type: text/plain; charset=iso-8859-1 Unlike some other parameter values, the values of the charset parameter are NOT case sensitive. The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII. The specification for any future subtypes of "text" must specify whether or not they will also utilize a "charset" parameter, and may possibly ressortingct its values as well. For other subtypes of "text" than "text/plain", the semantics of the "charset" parameter should be defined to be identical to those specified here for "text/plain", ie, the body consists entirely of characters in the given charset. In particular, definers of future "text" subtypes should pay close attention to the implications of multioctet character sets for their subtype definitions. 

Selon eux, de telles difficultés peuvent être évitées en utilisant le type MIME application/xml . Que ce soit vrai ou non, je n’irais pas jusqu’à éviter text/xml . À mon humble avis, il est préférable de suivre la sémantique de la lisibilité humaine (non-lisibilité) et de ne jamais oublier de spécifier le jeu de caractères.

application/xml est vue par svn comme type binary, alors que text/xml est un fichier texte pour lequel un diff peut être affiché.