La meilleure façon de décider de la réponse XML ou HTML?

Question

J'ai une ressource à une URL que les humains et les machines doivent pouvoir lire:

http://example.com/foo-collection/foo001

Quelle est la meilleure façon de faire la distinction entre les navigateurs humains et les machines, et le retour HTML ou un domaine- réponse XML spécifique?

(1) Le champ Type d'acceptation de la demande?

(2) Un bit d'URL supplémentaire? par exemple:

http://example.com/foo-collection/foo001 -> HTML retourne
http://example.com/foo-collection/foo001?xml -> retours, euh, XML

Je ne veux pas obliger les machines à lire la ressource pour analyser HTML (ou XHTML pour cette matière). Les machines comme googlebot devraient recevoir la réponse HTML.

Il est raisonnable de supposer que je contrôle les lecteurs de la machine.

Answer 1

Je dirais que l'ajout d'un paramètre Query String est votre meilleur choix. La seule façon de détecter automatiquement si votre client est un navigateur (humain) ou une application serait de lire la chaîne User-Agent à partir de la requête HTTP. Mais cela est facilement défini par n'importe quelle application pour imiter un navigateur, vous n'êtes pas sûr que cela va fonctionner.

Answer 2

Si cela est sous votre contrôle, plutôt que d'ajouter un paramètre de requête pourquoi ne pas ajouter une extension de fichier:

http://example.com/foo-collection/foo001.html - return HTML 
http://example.com/foo-collection/foo001.xml - return XML 

En dehors de toute autre chose, cela signifie que si quelqu'un, il va chercher avec wget ou il sauve de leur navigateur , il aura un nom de fichier approprié sans aucun problème.

Answer 3

Ma préférence est d'en faire une partie de première classe de l'URI. C'est discutable, car il y a - en un sens - plusieurs URI pour la même ressource. Et le "format" fait-il vraiment partie de l'URI?

http://example.com/foo-collection/html/foo001 
http://example.com/foo-collection/xml/foo001 

Il est très facile de traiter ces problèmes dans un framework web qui a une analyse d'URI pour diriger la requête vers l'application appropriée.

Answer 4

S'il s'agit bien de la même ressource avec deux représentations différentes, le HTTP vous invite à utiliser the Accept-header comme vous le suggérez. C'est probablement un moyen très fiable de distinguer les deux scénarios différents. Vous pouvez être sûr que les agents utilisateurs (y compris les moteurs de recherche) envoient correctement l'en-tête Accept.

A propos des agents machine que vous allez donner XML; Sont-ils sous votre contrôle? Dans ce cas, vous pouvez être doublement sûr qu'Accept fonctionnera. S'ils ne définissent pas cet en-tête correctement, vous pouvez donner XML par défaut. Les agents utilisateurs définissent correctement l'en-tête.

Je voudrais essayer d'utiliser le Accept heder pour cela, parce que c'est exactement ce que l'en-tête Accept est là pour. Le problème avec deux URL différentes est qu'il n'est pas automatiquement apparent que ces deux représentent la même ressource sous-jacente. Cela peut être mauvais si un utilisateur trouve une URL dans un programme, ce qui rend HTML, et le colle dans l'autre, qui a besoin de XML.À ce stade, un utilisateur averti pourrait probablement modifier l'URL de manière appropriée, mais ce n'est qu'une source d'erreur dont vous n'avez pas besoin.