REST Content-Type : Doit-il être basé sur l'extension ou l'en-tête Accept ?

Question

La représentation (html, xml, json) renvoyée par un service web RESTful doit-elle être déterminée par l'url ou par l'en-tête HTTP Accept ?

Answer 1

Les deux sont valables. Citation de xml.com :

Une ressource peut avoir plus d'une représentation. Il existe quatre moyens fréquemment utilisés pour fournir la représentation correcte de la ressource aux consommateurs :

1. Négociation pilotée par le serveur. Le fournisseur de services détermine la bonne représentation à partir de la connaissance préalable de ses clients ou utilise les informations fournies dans les en-têtes HTTP comme Accept, Accept-Charset, Accept-Encoding, Accept-Language, et User-Agent. L'inconvénient de cette approche, inconvénient de cette approche est que le serveur peut ne pas avoir la meilleure connaissance de ce que le client veut vraiment.
2. La négociation axée sur le client. Un client lance une demande à un serveur. Le serveur renvoie une liste de de représentations disponibles. Le site client sélectionne alors la représentation qu'il souhaite et envoie une deuxième demande au au serveur. L'inconvénient est qu'un client doit envoyer deux requêtes.
3. Négociation par procuration. Un client lance une demande à un serveur par l'intermédiaire d'un proxy. Le proxy transmet la demande au serveur et obtient une liste de représentations. Le proxy sélectionne une représentation en fonction selon les préférences définies par le client et renvoie la représentation au client. client.
4. Représentation spécifiée par URI. Un client spécifie la représentation qu'il souhaite qu'il souhaite dans la chaîne d'interrogation de l'URI.

Answer 2

C'est une non-question.

L'acceptation dépend de conneg (négociation du contenu). Conneg laissera le client décider du type de média qu'il accepte par le biais de l'en-tête Accept :. La réponse sera alors dans ce format, accompagnée d'un en-tête Vary : Accept.

D'autre part, il est également possible et parfaitement valable d'exposer votre ressource en tant que /resource.json et /resource.xml.

L'idéal est d'implémenter les deux : /resource (uri générique qui supporte les conneg) /resource.xml /resource.json

la version connectée renvoyée par /resource peut simplement rediriger vers l'uri correct en fonction du type de média négocié. Alternativement, la représentation correcte peut être renvoyée à partir de l'uri générique, et utiliser Content-Location pour spécifier la représentation spécifique qui a été renvoyée.

Answer 3

Puisque vous mentionnez un service web RESTful et non n'importe quel service web, j'opterais fortement pour ce qui est pris en charge par la norme sous-jacente, à savoir HTTP 1.1 et sa négociation de contenu qui s'appuie sur Accept En-tête HTTP.

Comme je l'ai expliqué dans ma réponse à Puis-je modifier les en-têtes de la requête HTTP envoyée par le navigateur ? L'adresse (URI) et la représentation sont deux piliers distincts d'une conception RESTful et il n'est pas nécessaire de les mélanger. Il ne faut pas abuser des URI pour intégrer des représentations acceptables quand il y a Accept en-tête .

Ce n'est que si votre application web est susceptible d'être exécutée et utilisée dans un environnement où les nœuds intermédiaires effectuent un certain filtrage des en-têtes HTTP que vous devez prendre en charge la négociation de contenu basée sur les URI. En vérité, de tels proxies intrusifs ou fonctionnant mal doivent être remplacés si cela est possible et faisable.

A la vôtre !
Shonzilla

Answer 4

Utiliser l'en-tête Accept, s'il est fourni, l'URI comme basculement.

Answer 5

L'utilisation du type de contenu pose des problèmes... J'en ai parlé sur mon blog http://shouldersofgiants.co.uk/Blog et nous avons finalement décidé d'inclure la représentation dans l'URI, comme suggéré dans RESTful Web Services de Richardson et Ruby.