Barre oblique de fin dans l'API RESTful
J'ai eu un débat sur ce qu'il faut faire avec une barre oblique finale dans une API RESTful.
Disons que j'ai une ressource appelée chiens et des ressources subordonnées pour les chiens individuels. On peut donc faire ce qui suit:
GET/PUT/POST/DELETE http://example.com/dogs
GET/PUT/POST/DELETE http://example.com/dogs/{id}
Mais que faisons-nous avec le cas spécial suivant:
GET/PUT/POST/DELETE http://example.com/dogs/
Mon opinion personnelle est que cela signifie envoyer une demande à une ressource de chien individuelle avec id = null. Je pense que l'API devrait renvoyer un 404 pour ce cas.
D'autres disent que la demande accède à la ressource chiens, c'est-à-dire que la barre oblique de fin est ignorée.
Quelqu'un connaît-il la réponse définitive?
Rien de tout cela fait autorité (comme REST n'a pas de signification exacte). Mais d'après l'article original sur REST une URL complète (ne se terminant pas par /) une URL ressource, tandis que celui qui se termine par une barre oblique "/" est un groupe de ressources (probablement pas libellé comme ça).
Un GET d'une URL avec une barre oblique à la fin est censé répertorier les ressources disponibles.
GET http://example.com/dogs/ /* List all the dogs resources */
Un PUT sur une URL avec une barre oblique est censé remplacer toutes les ressources.
PUT http://example.com/dogs/ /* Replace all the dogs resources */
UNE SUPPRESSION sur une URL avec une barre oblique est censée supprimer toutes les ressources
DELETE http://example.com/dogs/ /* Deletes all the dogs resources */
Un POST sur une URL avec une barre oblique est censé créer une nouvelle ressource peut ensuite être consulté ultérieurement. Pour être conforme, la nouvelle ressource doit être dans ce répertoire (bien que beaucoup d'architectures RESTful trichent ici)) .
POST http://example.com/dogs/ /* Creates a new dogs resource (notice singular) */
etc.
La page wiki sur le sujet semble bien l'expliquer:
Voir l'exemple https://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_Web_services .
Does anyone know the definitive answer?
Il n'y en a pas car il n'y a pas de document officiel sur ce qui est requis pour qu'un service soit considéré comme RESTful.
Cela dit, je permettrais la barre oblique de fin simplement pour la facilité d'utilisation. Bien que techniquement parlant, cela puisse être considéré comme une tentative d'accès à un chien avec une pièce d'identité nulle; Je ne vois pas un utilisateur faire ce saut à moins qu'il ne l'ait lu dans votre documentation. Je peux voir un utilisateur tenter d'écrire du code contre votre API et inclure la barre oblique de fin simplement par habitude et se demander pourquoi il obtient une réponse 404 lorsqu'il veut une liste de chiens.
Deux façons.
Méthode 1
tilisez toujours des barres obliques de fin pour toute ressource pouvant contenir des enfants.
Considérez simplement "GET" sur un répertoire public_html avec des fichiers.
Impossible lorsque hello.html est un fichier:
/hello.html
/hello.html/youagain.html
Mais possible lorsque hello.html est un répertoire:
/hello.html/ (actually /hello.html/index.html)
/hello.html/youagain.html
Donc, si "hello.html" peut avoir des enfants, c'est toujours et toujours "/hello.html/" et "/hello.html/index.html" (ou simplement /hello.html/) est une liste de ces enfants .
Méthode 2
Soyez "intelligent".
$ find
.
./hello.html
./hello.html/index.html
La commande find ne se soucie pas du type de hello.html. Répertoire ou fichier, peu importe, c'est le nom d'un objet. Lorsque nous écrivons "cp youagain.html hello.html", cp peut comprendre comment gérer hello.html. cp est intelligent. Votre serveur Web est également intelligent. Il possède une bibliothèque de gestion des chemins. Il a un routage. Il peut stat et vous dire si un nom est un objet ou un répertoire. Il peut rediriger bla vers bla/ou même simplement servir la même réponse pour les deux. C'est génial !!! façon. Tant de technologie. Qui voudrait jamais simplement concaténer des chaînes de chemin alors que nous pourrions faire tout ça ???