URL RESTful et des dossiers

Question

Sur le Microformats spec for RESTful URLs:

GET /people/1
retour le premier enregistrement au format HTML

GET /people/1.html
retour le premier enregistrement au format HTML

et /people retourne une liste de personnes

Ainsi est /people.html le moyen correct de renvoyer une liste de personnes au format HTML?

Answer 1

Si vous venez de référence à l'extension de chemin d'URL, alors, oui, ce régime est le comportement recommandé pour la négociation de contenu:

chemin
• sans extension est une URL générique (par exemple /people pour tout format accepté)
chemin
• avec l'extension est une URL spécifique (par exemple /people.json comme URL-type de contenu pour le format de données JSON)

avec un tel système, le serveur peut utiliser la négociation de contenu lorsque l'URL générique est demandé et répondre avec une représentation spécifique lorsqu'une URL spécifique est demandée.

Les documents qui recommandent ce programme sont entre autres:

• Cool URIs don't change
• Cool URIs for the Semantic Web
• Content Negotiation: why it is useful, and how to make it work

Answer 2

Il est dit que GET /people/1.json doit retourner le premier enregistrement au format JSON. - Ce qui est logique.

Answer 3

Vous avez la bonne idée. Les deux /people et /people.html renverraient des listes de personnes au format HTML et /people.json renverraient une liste de personnes au format JSON.

Il ne devrait pas y avoir de confusion à ce propos en ce qui concerne l'application d'extensions de type de données aux "dossiers" dans les URL. Dans la liste des exemples, /people/1 est lui-même utilisé comme un dossier pour diverses autres requêtes.

Answer 4

URIs et comment vous les concevoir ont rien à voir avec RESTful ou ne pas.

C'est une pratique courante de faire ce que vous demandez, puisque fonctionne comme le serveur web Apache. Disons que vous avez foo.txt et foo.html et foo.pdf, et demandez à GET /foo sans préférence (c'est-à-dire sans Accept: en-tête). Un 300 MULTIPLE CHOICES serait retourné avec une liste des trois fichiers que l'utilisateur pourrait choisir. Parce que les navigateurs font une telle négociation de contenu, il est difficile de lier un exemple, mais voici: An example montre à quoi ça ressemble, sauf que la raison pour laquelle vous voyez la page en premier lieu est la casse du nom du fichier (" XSLT "vs" xslt ").

Mais ce comportement Apache est répercuté dans les conventions et les différents outils, mais ce n'est vraiment pas important. Vous pouvez avoir people_html ou people?format=html ou people.html ou sandwiches ou 123qweazrfvbnhyrewsxc6yhn8uk comme l'URI qui renvoie les personnes au format HTML. Le client ne connaît aucun de ces URI à l'avant, il est censé apprendre cela à partir d'autres ressources. Un humain pourrait voir le résultat de <a href="/sandwiches">All People (HTML format)</a> et comprendre ce qui se passe, tout en ignorant l'étrange URI.

Sur une note de clôture, la page conventions d'URL microformats est absolument pas une spécification pour les URL RESTful, il est simplement des conseils à rendre URIs qui, apparemment, sont faciles à consommer par les différentes bibliothèques HTTP pour une raison ou une autre, et n'a rien à voir avec REST du tout. Les directives sont toutes parfaitement correctes, et les suivre rend vos URIs saines pour d'autres personnes qui se trouvent sur les URI (/sandwiches est certes étrange). Mais même le protocole AtomPub cité ne nécessite pas d'entrées pour vivre "dans" la collection ...