REST - Compromis entre la négociation de contenu via l'en-tête Accept et les extensions

Je travaille à la conception d'une API RESTful. Nous savons que nous voulons renvoyer JSON et XML pour une ressource donnée. J'avais pensé que nous ferions quelque chose comme ceci:

GET /api/something?param1=value1
Accept:  application/xml (or application/json)

Cependant, quelqu'un a jeté en utilisant des extensions pour cela, comme ceci:

GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1)

Quels sont les compromis avec ces approches? Est-il préférable de s'appuyer sur l'en-tête accept lorsqu'une extension n'est pas spécifiée, mais de respecter les extensions lorsqu'elles sont spécifiées? Y a-t-il un inconvénient à cette approche?

Ceci, "Cependant, philosophiquement - la première approche est la seule approche.", Et ceci "La bonne approche officielle REST est d'utiliser Accept: en-tête." sont largement perçus comme étant le cas, mais sont également absolument incorrects .

Voici un bref extrait de Roy Fielding (qui a défini REST) ​​...

"La section 6.2.1 ne dit pas que la négociation de contenu doit être utilisée tout le temps." citer

Cette conversation particulière se situe dans le contexte de l'en-tête "Accept-Language:", mais il en va de même pour l'en-tête "Accepter:", comme cela sera précisé ultérieurement dans sa réponse ...

"Je ne sais pas pourquoi les gens ne peuvent pas voir les deuxième et troisième liens en haut de la page

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

ce point aux deux éditions PDF. "

Ce qu'il veut dire par là, c'est qu'il n'y a pas de problème à utiliser différents points de terminaison pour différentes représentations des mêmes données source. (Dans ce cas, un point de terminaison .html et deux points de terminaison .pdf différents.)

Toujours dans une discussion similaire, cette fois sur les avantages d'utiliser des paramètres de requête par rapport à l'utilisation d'extensions de fichiers pour différents types de supports ...

"C’est pourquoi je préfère toujours les extensions. Aucun choix n’a rien à voir avec REST." citer

Encore une fois, cela diffère légèrement de l'acceptation par rapport aux extensions de nom de fichier, mais la position de Fielding est toujours claire.

Réponse - peu importe vraiment. Les compromis entre les deux ne sont pas très importants et les deux sont des styles acceptables.

L'approche officielle RESTful appropriée consiste à utiliser l'en- Accept:tête.

Cependant, vous devez faire attention à ne pas casser la capacité de mise en cache, qui est l'une des exigences de REST. Vous devez avoir un en- Vary: Accepttête et un cache qui le comprend. Dans un monde idéal, vous l'auriez, mais dans la vie réelle, votre budget peut varier. La deuxième solution n'est donc pas aussi propre, mais elle pourrait être plus pratique.

Notez également que certains très anciens navigateurs ignoraient les en-têtes, s’appuyant plutôt sur l’extension.

Techniquement, cela n'a pas vraiment d'importance - votre serveur Web sera en mesure de le traiter comme il se doit. (Je suppose cela, mais ne ressemble pas à un obstacle).

Cependant, philosophiquement - la première approche est la seule approche. En mode REST, l’URL pointe en fait uniquement sur un URI - qui n’est qu’une ressource. Pensez un instant à cette ressource comme à un objet en programmation orientée objet. Vous parlez à cette ressource par le biais de seulement 4 méthodes (GET / POST / PUT / DELETE - ou si tout ce que le transport permet), mais cette méthode ne devient pas une description d'objet. De la même manière, la valeur renvoyée par l'aspect n'est pas l'URI. L'objet est toujours quelque chose et non quelque chose.xml ou quelque chose.json

Supposons que si vous ne souhaitez pas utiliser l'en-tête Accept, mais que vous souhaitiez tout de même être véritablement REST philosophiquement, cela ne me dérange pas:

GET /api/something?parm1=value1&return_type=xml

par opposition à

GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1)

Mais comme je l'ai dit, cette différence n'est que philosophique.

@vartec: je pense que tu as tort

Selon le principe officiel RESTful, rien ne doit être caché dans les en-têtes HTTP, car c’est l’URI qui est exposé ou référencé; tout détail de la demande / réponse doit être fourni avec l’URI.

Par conséquent, je recommande fortement d'éviter d'utiliser l'en-tête pour les détails concernant la demande et la réponse, et s'en tenir à

 GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1)

Je ne parviens pas à trouver rapidement les références, mais je vous répondrai avec elles (vous pouvez vous reporter au livre de publication d'O'reilly "RESTful Web Services" ( http://shop.oreilly.com/product/9780596529260.do ). qui confirme le même