Faire REST Les URL des API doivent ressembler à ceci?
Est-il vrai que pour implémenter une API RESTful, il faut implémenter une structure d'URL ressemblant à ceci
http://example.com/post/
http://example.com/post/123
où le /123 serait utilisé pour éditer, supprimer
Une autre façon de poser la question est la suivante: une URL ressemblant à ceci peut-elle s'appeler RESTful?
http://example.com/script.php?method=get_title&blogid=123
Vous n'avez pas devez concevoir votre structure d'URI comme ça. Il pourrait également s'agir de /some_obscure_string/base64_encoded_title/unique_id. Cela pourrait également être RESTful, en fonction de plusieurs autres facteurs.
Cependant, il existe plusieurs meilleures pratiques sur la manière de concevoir des URI dans une application Web RESTful. Le plus simple et lisible pour l'homme est l'une d'entre elles.
Votre exemple http://example.com/script.php?method=get_title&blogid=123 peut également être RESTful, mais les paramètres de requête indiquent qu'un type de RPC ou RMI sur HTTP est utilisé à la place.
En résumé: Ne réfléchissez pas trop à votre conception d'URI. Cela viendra automatiquement avec une bonne conception RESTful de votre application.
L’idée derrière REST est que chaque ressource a sa propre URL et que vous utilisez les différentes méthodes HTTP pour interagir avec ces ressources. Il est judicieux de définir la structure de l’URL afin que la hiérarchie entre les différentes ressources soit reflétée dans l’URL, mais ce n’est pas obligatoire.
Si vous avez des URL comme celle-ci
/all-posts/
/first-post
/some-stuff/second-post
/third-post
vous pouvez toujours fournir une API RESTful à cela. L'idée est qu'une GET à /all-posts/ renvoie une liste des URL de chaque objet de publication et que le client utilise ces URL pour interagir avec les ressources. Fondamentalement, les URL doivent être traitées comme des données opaques par le client.
Tant que l’URL incorporée dans le client ne change pas, vous pouvez également modifier la structure sans avoir à changer le client.
Votre exemple d’URL n’appartient probablement pas à une API RESTful, car il contient une méthode get_title. Dans REST, une URL représente une chose . Ce qu'il faut faire avec la chose (si elle doit être modifiée, si son contenu doit être récupéré, ...) ne fait pas partie de l'URL, car REST utilise les différentes méthodes HTTP.
Un aspect clé de REST est que l'URL est la ressource. un uri comme
http://example.com/script.php?etc-etc-etc
ne met pas l'identifiant de ressource dans la partie ressource de l'URI. Cela ne veut pas dire qu'une API RESTful ne devrait jamais utiliser des paramètres get; en fait, c'est très bien:
http://example.com/posts?sort=date_asc&offset=20&limit=10
pourrait être un excellent moyen d’obtenir l’URI de la 3ème page des publications les plus anciennes. Toutefois, l’utilisation des paramètres get de cette manière ne devrait être utilisée que dans les requêtes où la méthode est également GET. Les méthodes PUT et surtout POST devraient vraiment utiliser des uri simples avec la ressource qui ne sera affectée que dans la partie chemin.
La conception d'URI RESTful concerne uniquement l'accès aux ressources. Elles doivent être structurées de manière RESTful. Vous ne devez donc pas avoir de chaîne de requête.
par exemple. de GET
auteurs/
auteurs/1
auteurs/1/livres
auteurs/1/livres/10
auteurs/1/livres/10/résumé
etc.
Tout le reste s'appelle RESTfull ces jours-ci, il suffit de regarder certaines des réponses de son inventeur, le Dr Roy Fielding, et vous obtiendrez quelques idées. Cela vaut la peine de lire un peu sur le sujet.
Si vous n'avez pas besoin de poster, inscrivez etc. dans vos URI, le protocole HTTP est actuellement principalement utilisé pour la consommation des API REST et vous pouvez passer un verbe dans le cadre de l'appel. Il existe également un concept de négociation de contenu, c’est-à-dire que vous pouvez demander n’importe quel format disponible à la REST API (json, xml atc).
Exemple d'URL:
GET http://del.icio.us/api/
GET http://del.icio.us/api/peej/tags/
GET http://del.icio.us/api/peej/tags/test
DELETE http://del.icio.us/api/peej/bookmarks/[hash]
Le concept REST repose en réalité sur le fait qu'il est géré par une URL et non par de gros fichiers de données. Avec REST, vous n'avez pas besoin de passer une requête soap géante pour appeler une méthode. Votre méthode call call/object creation/que vous voulez faire est invoquée simplement par l'URL et le verbe que vous avez utilisé par rapport à cette URL.
La structure de vos URL n'a pas d'importance. L’important est que chaque URL identifie exactement 1 ressource. Chaque ressource peut avoir plusieurs URL pointant vers elle, mais chaque URL ne doit pointer que vers une ressource.