nous devons renvoyer toutes les données d'article à l'API pour la mise à jour et le travail multi-utilisateur n'a pas pu être mis en œuvre. Par exemple, l'éditeur pourrait envoyer des données plus anciennes de 5 secondes et corriger un écrasement qu'un autre journaliste vient de faire il y a 2 secondes. Je ne peux absolument pas expliquer cela aux clients, car ceux qui publient un article ne sont aucunement liés à la mise à jour du contenu.
Peu importe ce que vous faites, ce type de problème est un défi. Il s'agit d'un problème très similaire au contrôle de source distribué (mercurial, git, etc.), et la solution, épelée dans HTTP / ReST, semble un peu similaire.
Supposons que deux utilisateurs, Alice et Bob, travaillent tous les deux /articles/lunch
. (pour plus de clarté, la réponse est en gras)
Tout d’abord, alice crée l’article.
PUT /articles/lunch HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic YWxpY2U6c2VjcmV0
Hey Bob, what do you want for lunch today?
301 Moved Permanently
Location: /articles/lunch/1
Le serveur n'a pas créé de ressource, car il n'y avait pas de "version" attachée à la demande (en supposant un identifiant de /articles/{id}/{version}
. Pour effectuer la création, Alice a été redirigée vers l'URL de l'article / de la version qu'elle va créer. L'utilisateur d'Alice L'agent réappliquera alors la demande à la nouvelle adresse.
PUT /articles/lunch/1 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic YWxpY2U6c2VjcmV0
Hey Bob, what do you want for lunch today?
201 Created
Et maintenant, l'article a été créé. Ensuite, Bob regarde l'article:
GET /articles/lunch HTTP/1.1
Host: example.com
Authorization: Basic Ym9iOnBhc3N3b3Jk
301 Moved Permanently
Location: /articles/lunch/1
Bob regarde là:
GET /articles/lunch/1 HTTP/1.1
Host: example.com
Authorization: Basic Ym9iOnBhc3N3b3Jk
200 Ok
Content-Type: text/plain
Hey Bob, what do you want for lunch today?
Il décide d'ajouter sa propre monnaie.
PUT /articles/lunch/1 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic Ym9iOnBhc3N3b3Jk
Hey Bob, what do you want for lunch today?
Does pizza sound good to you, Alice?
301 Moved Permanently
Location: /articles/lunch/2
Comme avec Alice, Bob est redirigé vers où il créera une nouvelle version.
PUT /articles/lunch/2 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic Ym9iOnBhc3N3b3Jk
Hey Bob, what do you want for lunch today?
Does pizza sound good to you, Alice?
201 Created
Finalement, Alice décide d’ajouter à son propre article:
PUT /articles/lunch/1 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic YWxpY2U6c2VjcmV0
Hey Bob, what do you want for lunch today?
I was thinking about getting Sushi.
409 Conflict
Location: /articles/lunch/3
Content-Type: text/diff
---/articles/lunch/2
+++/articles/lunch/3
@@ 1,2 1,2 @@
Hey Bob, what do you want for lunch today?
-Does pizza sound good to you, Alice?
+I was thinking about getting Sushi.
Au lieu d'être redirigé normalement, un code d'état différent est renvoyé au client 409
, ce qui indique à Alice que la version à partir de laquelle elle essayait de créer une branche a déjà été créée. De toute façon, les nouvelles ressources ont été créées (comme le montre l'en- Location
tête) et les différences entre les deux ont été incluses dans le corps de la réponse. Alice sait maintenant que la demande qu'elle vient de faire doit être fusionnée en quelque sorte.
Toute cette redirection est liée à la sémantique de PUT
, ce qui nécessite la création de nouvelles ressources exactement à l'endroit demandé par la ligne de requête. cela pourrait aussi économiser un cycle de requête en utilisant la POST
place, mais le numéro de version devrait alors être encodé dans la requête par une autre magie, ce qui me paraissait moins évident aux fins d'illustration, mais serait probablement préféré dans une vraie API. minimiser les cycles de demande / réponse.
api/article?action=publish
? Les paramètres de requête sont destinés aux cas où l'état de la ressource dépend de l'algorithme (ou de l'action) que vous mentionnez. Par exemple,api/articles?sort=asc
est valide