(désolé, ma première fois, j'ai raté le / modifier / et / supprimer / dans (2) ...)
L'idée de l'URI est qu'il s'agit d'un identifiant d'une ressource adressable , plutôt que d'un appel de méthode . L'URI doit donc pointer vers une ressource spécifique. Et si vous respectez l'URI, vous devriez toujours obtenir la même ressource.
Autrement dit, vous devez penser aux URI de la même manière que vous pensez à la clé primaire d'une ligne dans une base de données. Il identifie de façon unique quelque chose: Universal Resource Identifier.
Donc, que vous utilisiez le pluriel ou le singulier, l'URI doit être un identifiant plutôt qu'une invocation . Ce que vous essayez de faire va dans la méthode, à savoir: GET (get), PUT (create / update), DELETE (delete) ou POST (tout le reste).
Donc "/ item / delete / 123" rompt REST car il ne pointe pas vers une ressource, il s'agit plus d'un appel de méthode.
(En outre, juste sémantiquement, vous devriez pouvoir obtenir un URI, décider qu'il est obsolète, puis SUPPRIMER le même URI - car il s'agit d'un identifiant. Si l'URL GET n'a pas "/ delete /" et DELETE en a, alors cela va à l'encontre de la sémantique HTTP. Vous diffusez 2 URI ou plus par ressource où 1 fera l'affaire.)
Maintenant, la triche est la suivante: il n'y a pas de véritable définition claire de ce qui est et n'est pas une ressource, donc l'esquive commune dans REST est de définir un "nom de traitement" et de pointer l'URI vers cela. C'est à peu près un jeu de mots, mais cela satisfait la sémantique.
Donc, si, par exemple, vous ne pouviez vraiment pas l'utiliser pour une raison quelconque:
DELETE /items/123
vous pouvez déclarer au monde que vous disposez d'une ressource de traitement "suppresseur" et utiliser
POST /items/deletor { id: 123 }
Maintenant, cela ressemble beaucoup à RPC (Remote Procedure Call), mais cela passe par la vaste échappatoire de la clause de "traitement des données" de la spécification POST nommée dans la spécification HTTP.
Cependant, cela est un peu exceptionnel, et si vous pouvez utiliser le PUT commun pour créer / mettre à jour, DELETE pour supprimer et POST pour ajouter, créer et tout le reste, vous devriez , car c'est une utilisation plus standard de HTTP. Mais si vous avez un cas délicat comme "commit" ou "publish" ou "redact", alors le cas de l'utilisation d'un nom de processeur satisfait les puristes REST et vous donne toujours la sémantique dont vous avez besoin.
PUT
etDELETE
, je préférerais l'ajouter au chemin, pas le différencier avec une chaîne de requête. Ce n'est pas une modification de chaîne de requête à une opération existante; c'est une opération distincte.