Quels sont les meilleurs verbes et actions d'URL RESTful?
J'essaie de trouver des informations sur les actions d'URL RESTful les meilleures et les plus courantes.
par exemple, quelle URL utilisez-vous pour afficher les détails d'un élément, pour modifier l'élément, mettre à jour, etc.
/question/show/<whatever>
/question/edit/<whatever>
/question/update/<whatever> (this is the post back url)
/question/list (lists the questions)
hmm. merci à tous ceux qui nous aident :)
Utilisez des URL pour spécifier vos objets, pas vos actions:
Notez que ce que vous avez mentionné en premier n'est pas RESTful:
/questions/show/<whatever>
À la place, vous devez utiliser vos URL pour spécifier vos objets:
/questions/<question>
Ensuite, vous effectuez l'une des opérations ci-dessous sur cette ressource.
OBTENIR:
Utilisé pour obtenir une ressource, interroger une liste de ressources et également interroger des informations en lecture seule sur une ressource.
Pour obtenir une ressource de questions:
GET /questions/<question> HTTP/1.1
Host: whateverblahblah.com
Pour répertorier toutes les ressources de questions:
GET /questions HTTP/1.1
Host: whateverblahblah.com
POST:
Utilisé pour créer une ressource.
Notez que ce qui suit est une erreur:
POST /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com
Si l'URL n'est pas encore créée, vous ne devez pas utiliser POST pour la créer tout en spécifiant le nom. Cela devrait entraîner une erreur de ressource introuvable car elle n'existe pas encore. Vous devez METTRE le Vous pouvez faire valoir qu'en créant une nouvelle question, vous mettez également à jour la ressource/questions car elle renverrait désormais une autre question dans sa liste de questions.
Vous devriez faire quelque chose comme ceci pour créer une ressource à l'aide de POST:
POST /questions HTTP/1.1
Host: whateverblahblah.com
Notez que dans ce cas, le nom de la ressource n'est pas spécifié, le nouveau chemin d'URL des objets vous sera retourné.
SUPPRIMER:
Utilisé pour supprimer la ressource.
DELETE /questions/<question> HTTP/1.1
Host: whateverblahblah.com
PUT:
Utilisé pour créer une ressource ou l'écraser pendant que vous spécifiez l'URL des ressources.
Pour une nouvelle ressource:
PUT /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com
Pour remplacer une ressource existante:
PUT /questions/<existing_question> HTTP/1.1
Host: whateverblahblah.com
...Oui, ils sont pareils. PUT est souvent décrit comme la méthode "modifier", car en remplaçant la ressource entière par une version légèrement modifiée, vous avez modifié ce que les clients OBTIENDRONT lors de leur prochaine étape.
Utilisation de REST dans les formulaires HTML:
La spécification HTML5 définit GET et POST pour l'élément de formulaire .
L'attribut de contenu de méthode est un attribut énuméré avec les mots-clés et états suivants:
- Le mot clé GET, mappant à l'état GET, indiquant la méthode HTTP GET.
- Le mot clé POST, mappant à l'état POST, indiquant la méthode HTTP POST.
Techniquement, la spécification HTTP ne vous limite pas uniquement à ces méthodes. Vous êtes techniquement libre d'ajouter toutes les méthodes que vous souhaitez, mais en pratique, ce n'est pas une bonne idée. L'idée est que tout le monde sait que vous utilisez GET pour lire les données, donc cela créera de la confusion si vous décidez d'utiliser plutôt READ. Cela dit...
PATCH:
Il s'agit d'une méthode qui a été définie dans un RFC formel. Il est conçu pour être utilisé lorsque vous souhaitez envoyer uniquement une modification partielle à une ressource, il serait utilisé un peu comme PUT:
PATCH /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com
La différence est que PUT doit envoyer la ressource entière, quelle que soit sa taille par rapport à ce qui a réellement changé, tandis que PATCH vous pouvez envoyer juste les changements.
En supposant /questions/10 est une question valide alors la méthode est utilisée pour interagir avec elle.
POST pour y ajouter
PUT pour le créer ou le remplacer
OBTENIR pour l'afficher/l'interroger
et SUPPRIMER pour bien .. supprimer.
L'URL ne change pas.
Je vais sortir sur une branche et deviner que vous voulez dire ce que sont les contrôleurs standard pour MVC lorsque vous dites des URL "RESTful", car vos exemples peuvent être considérés comme non "RESTful" (voir ce article).
Étant donné que Rails a vraiment popularisé le style d'URL qui semble vous intéresser, je propose ci-dessous les actions de contrôleur par défaut produites par ScaffoldingGenerator dans Ruby sur Rails. Ceux-ci devraient être familiers à toute personne utilisant une application Rails.
Les actions et vues échafaudées sont les suivantes: index, liste, afficher, nouveau, créer, éditer, mettre à jour, détruire
Typiquement, vous construisez ceci comme:
http://application.com/controller/<action>/<id>
Voici un mappage de vos URL actuelles en utilisant le principe REST:
/question/show/<whatever>
Si vous identifiez la question en tant que ressource, elle doit avoir une URL unique. Utiliser GET pour l'afficher (le récupérer) est la pratique courante. Il devient:
GET /question/<whatever>
/question/edit/<whatever>
Maintenant, vous voulez que votre utilisateur ait une autre vue de la même ressource qui lui permet de modifier la ressource (peut-être avec des contrôles de formulaire).
Deux options ici, votre application est une application (pas un site Web), alors vous pouvez mieux utiliser JavaScript pour transformer la ressource en une ressource modifiable côté client.
S'il s'agit d'un site Web, vous pouvez utiliser la même URL avec des informations supplémentaires pour spécifier une autre vue, la pratique courante semble être:
GET /question/<whatever>;edit
/question/update/<whatever> (this is the post back url)
C'est pour changer la question, donc PUT est la bonne méthode à utiliser:
PUT /question/<whatever>
/question/list (lists the questions)
La liste de questions est en fait la ressource parent d'une question, elle est donc naturellement:
GET /question
Maintenant, vous pourriez en avoir besoin de plus:
POST /question (create a new question and returns its URL)
DELETE /question/<whatever> (deletes a question if this is relevant)
Tada :)