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>
Au lieu de cela, 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.
AVOIR:
Utilisé pour obtenir une ressource, interroger une liste de ressources et également pour interroger des informations en lecture seule sur une ressource.
Pour obtenir une ressource de question:
GET /questions/<question> HTTP/1.1
Host: whateverblahblah.com
Pour lister toutes les ressources de questions:
GET /questions HTTP/1.1
Host: whateverblahblah.com
PUBLIER:
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 d'abord METTRE la ressource sur le serveur. Vous pourriez 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 en utilisant 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 chemin de l'URL des nouveaux objets vous sera renvoyé.
SUPPRIMER:
Utilisé pour supprimer la ressource.
DELETE /questions/<question> HTTP/1.1
Host: whateverblahblah.com
METTRE:
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 écraser 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 «éditer», car en remplaçant la ressource entière par une version légèrement modifiée, vous avez édité ce que les clients OBTENIRont la prochaine fois.
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, mappé à 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 à ces seules méthodes. Vous êtes techniquement libre d'ajouter les méthodes que vous voulez, mais dans la 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 va dérouter les choses si vous décidez d'utiliser à la place READ. Cela dit...
PIÈCE:
Il s'agit d'une méthode qui a été définie dans une RFC formelle. Il est conçu pour être utilisé lorsque vous souhaitez envoyer juste 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 toute la ressource, quelle que soit sa taille par rapport à ce qui a réellement changé, tandis que PATCH vous permet d'envoyer uniquement les modifications.
En supposant
/questions/10que la question soit valide, la méthode est utilisée pour interagir avec elle.POST pour y ajouter
PUT pour le créer ou le remplacer
OBTENEZ pour voir / interroger
et SUPPRIMER pour bien .. le supprimer.
L'URL ne change pas.
la source
Je vais sortir sur une branche et deviner que vous ce que vous voulez dire est ce que sont les contrôleurs standard pour MVC quand vous dites "RESTful" urls, puisque vos exemples pourraient être considérés comme non "RESTful" (voir cet article).
Comme 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 le ScaffoldingGenerator dans Ruby on Rails. Ceux-ci doivent être familiers à toute personne utilisant une application Rails.
En règle générale, vous construisez ceci comme suit:
la source
Voici un mappage de vos URL actuelles en utilisant le principe REST:
Si vous identifiez la question comme une ressource, elle doit avoir une URL unique. Utiliser GET pour l'afficher (le récupérer) est la pratique courante. Il devient:
Vous voulez maintenant que votre utilisateur ait une autre vue de la même ressource qui lui permette 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 feriez peut-être mieux d'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:
C'est pour changer la question, donc PUT est la bonne méthode à utiliser:
La liste de questions est en fait la ressource parente d'une question, c'est donc naturellement:
Maintenant, vous pourriez en avoir besoin de plus:
Tada :)
la source
Vos quatre exemples pourraient être:
Pour ajouter une question:
Le serveur répondrait:
la source