Lors de la conception d'une interface RESTful, la sémantique des types de demandes est considérée comme essentielle à la conception.
- GET - Lister une collection ou récupérer un élément
- PUT - Remplace la collection ou l'élément
- POST - Créer une collection ou un élément
- DELETE - Eh bien, erm, delete collection ou element
Cependant, cela ne semble pas couvrir le concept de "recherche".
Par exemple, lors de la conception d'une suite de services Web prenant en charge un site de recherche d'emploi, les conditions suivantes peuvent être remplies:
- Obtenir une offre d'emploi individuelle
- Se rendre à
domain/Job/{id}/
- Se rendre à
- Créer une offre d'emploi
- POST à
domain/Job/
- POST à
- Mettre à jour une offre d'emploi
- PUT à
domain/Job/
- PUT à
- Supprimer une offre d'emploi
- SUPPRIMER à
domain/Job/
- SUPPRIMER à
"Get All Jobs" est aussi simple:
- Se rendre à
domain/Jobs/
Cependant, comment la "recherche" d'emploi entre-t-elle dans cette structure?
Vous pouvez prétendre que c'est une variante de "list collection" et implémenter comme:
- Se rendre à
domain/Jobs/
Cependant, les recherches peuvent être complexes et il est tout à fait possible de générer une recherche générant une longue chaîne GET. En d’autres termes, si l’on fait référence à une question SO , il existe des problèmes liés à l’utilisation de chaînes GET plus longues que 2 000 caractères environ.
Un exemple pourrait être dans une recherche à facettes - en continuant l’exemple "job".
Je peux autoriser la recherche sur des facettes - "Technologie", "Titre du travail", "Discipline" ainsi que sur les mots-clés en texte libre, l'âge du travail, l'emplacement et le salaire.
Avec une interface utilisateur fluide et un grand nombre de technologies et de titres d'emploi, il est possible qu'une recherche englobe un grand nombre de choix de facettes.
Ajustez cet exemple en CV, plutôt qu'en emplois, apportez encore plus de facettes, et vous pouvez très facilement imaginer une recherche avec une centaine de facettes sélectionnées, ou même seulement 40 facettes de 50 caractères chacune (par exemple, Titres de poste, Noms d'université, Noms d’employeurs).
Dans cette situation, il peut être souhaitable de déplacer un PUT ou un POST afin de s’assurer que les données de recherche seront correctement envoyées. Par exemple:
- POST à
domain/Jobs/
Mais sémantiquement, c'est une instruction pour créer une collection.
Vous pouvez également dire que vous exprimerez ceci sous la forme d'une recherche:
- POST à
domain/Jobs/Search/
ou (comme suggéré par burninggramma ci-dessous)
- POST à
domain/JobSearch/
Sémantiquement, cela peut sembler logique, mais vous ne créez rien, vous faites une demande de données.
Donc, sémantiquement, c'est un GET , mais GET n'est pas garanti pour prendre en charge ce dont vous avez besoin.
La question est donc la suivante: essayer de rester aussi fidèle que possible à la conception RESTful tout en veillant à rester dans les limites du protocole HTTP, quelle est la conception la plus appropriée pour une recherche?
domain/Jobs?keyword={keyword}
. Cela fonctionne très bien pour moi :) J'espère que leSEARCH
verbe deviendra un standard. programmers.stackexchange.com/questions/233158/…