REST conception API des ressources avec de nombreuses opérations en fonction de l'état des ressources

Question

Je suis la conception d'une API REST pour la gestion des utilisateurs qui doivent prendre en charge les opérations de CRUD suivantes:

• créer un nouvel utilisateur (POST /users)
• mettre à jour un utilisateur existant (PUT /users/{userid})
• supprimer un utilisateur (DELETE) /users/{userid}
• détails get utilisateur (GET /users/{userid})

et les opérations qui dépendent de l'état de l'utilisateur:

• activer un utilisateur
• bloc utilisateur
• débloquer un utilisateur
• suspendre un utilisateur
• archive un utilisateur

La charge utile des demandes ci-dessus ne contient pas de représentation utilisateur. Il contient des informations telles que par ex. le reson pourquoi le est bloqué/suspendu/archivé.

Selon les bonnes pratiques de conception REST, les URI ne devraient pas être des opérations API, il y a donc d'autres façons que par ex. POST /users/{userid}/activate comment de telles opérations peuvent être mises en œuvre?

Answer 1

Selon la thèse de Roy T. Fielding, any information that can be named can be a REST resource:

5.2.1.1 Ressources et Resource Identifiers

L'abstraction clé de l'information dans REST est une ressource. Toute information qui peut être nommée peut être une ressource: un document ou une image, un service temporel (par exemple "la météo d'aujourd'hui à Los Angeles"), une collection d'autres ressources, un objet non virtuel (par exemple une personne), etc. . En d'autres termes, tout concept qui pourrait être la cible de la référence hypertexte d'un auteur doit correspondre à la définition d'une ressource. Une ressource est un mappage conceptuel à un ensemble d'entités, et non l'entité qui correspond au mappage à un moment donné. [...]

Depuis le statut appartient à un utilisateur , l'état peut être géré comme un sous-ressources de l'utilisateur ressources.

Pour y parvenir, vous pouvez avoir une URL comme /users/{userid}/status.

POST ou PUT peut être effectuée sur cette URL envoyer les informations pertinentes pour modifier le statut de l'utilisateur .

Answer 2

Deux options possibles sont par exemple:

modèle

• l'action d'être une partie de la ressource utilisateur (par exemple introduire un-Drapeau archivé qui peut être réglé). Avec cette approche il est bizarre de transmettre des informations supplémentaires sur l'événement (raison pour laquelle il a été archivé/bloqué/...), bien sûr.
• créer une ressource REST séparée, par ex. /api/archivedUsers/ où vous pouvez poster un tuple constitué d'utilisateur-URI et événements-données supplémentaires

les deux approches ont en commun, qu'ils tentent de modéliser l'état de votre objet utilisateur (REST-like), plutôt que d'effectuer une action sur lui (ce qui ressemble à RPC-like). Vous pouvez également vérifier cet article: REST API design resource modeling.