J'ai un service Web reposant qui représente des processus et des activités. Chaque activité est à l'intérieur d'un seul et un seul processus. Je voudrais représenter une opération d'activité «Move» entre le processus et un autre processus.
Je regarde des forums et j'ai trouvé que des personnes suggèrent d'utiliser le fonctionnement de déplacement qui n'est pas très standard et d'autres suggèrent d'utiliser Met, mais je ne sais pas comment dire la différence entre cette mise à jour et mettre ces mouvements qui ressemblent sémantiquement faux.
Des idées?
3 Réponses :
Une solution pourrait être de représenter le mouvement lui-même comme, dire, une ressource "transfert" (transfert en tant que nom) et poster une nouvelle: avec une entité contenant: de cette façon, les clients créent de nouveaux "transferts" qui, sur le serveur, gérer la validation et le transfert de l'activité. Cela vous donne la capacité Pour ajouter des informations sur le transfert, aussi. Si vous souhaitez conserver une histoire pour l'audit, vous pouvez ajouter une propriété transfertRedby sur la ressource ou à une date transféradon .
Bonjour, c'est une idée intéressante. Je n'ai pas pensé à utiliser le transfert lui-même en tant que ressource, mais je suppose que c'est ce que le reste est tout. Vous pensez qu'il est bon que, en créant (publier) une nouvelle ressource de transfert une autre ressource sera modifiée?
Oui, c'est parfaitement bien. Message ne doit pas nécessairement être idempotent , donc il peut avoir des effets secondaires.
+1. C'est la façon dont j'ai aussi pensé. Je pense que cela est plus propre que celui d'un élément contenu à chaque fois que le mouvement devrait affecter les deux, le conteneur (sa liste d'éléments contenus) et l'élément contenu (son champ de liaison parent). Cependant, je me demande si le repos est d'être propre dans ce sens. Est-ce que ça va de supposer que quelqu'un d'autre met sur le parent chaque fois que nous mettons à l'enfant? Ou devriez-nous vous soucier de bien corriger, même lorsque vous consultez l'ensemble des demandes réelles effectuées par un client?
Je ne pense pas avoir deux puts distincts viole le repos, mais cela fait une API plus encombrante et fait plus de travail au client pour assurer la transacalité de l'opération. Cela dépend principalement de la manière dont les clients doivent interagir avec le système et le mieux fonctionne pour cette interaction.
Cette approche convient parfaitement aux travaux de longue date, car une réponse au succès signifie que le travail a été ajouté à la file d'attente. Le client a alors la possibilité d'interroger le serveur pour la progression ou l'état d'emploi. Si vous déplacez cependant la ressource signifie essentiellement une colonne dans une base de données, j'irais une approche plus simple comme directement en utilisant Mettre à jour la ressource d'activité.
Si vous utilisez des mesures, vous pouvez indiquer la différence si le processus de l'entité existante correspond à la nouvelle.
303 See Other Location: /process2/activity2
Vous voudrez peut-être aussi utiliser "204 aucun contenu" au lieu des 303: GRZEGORZBORKOWSKI.BLOGSPOT.NL/2009/04/...
Que se passerait-il si vous mettre une seconde fois? Ne semble pas que mettre est Idempotent car il devrait être pour une API reposante.
@ahong Vous devriez obtenir un 404 non trouvé et aucun changement d'état. Ce serait idempotent.
Peut-être qu'une implémentation plus reposante serait d'utiliser mettre comme une commande copie (idempotent), puis supprimer ensuite, comme dans cette réponse: Stackoverflow.com/a/6709383
@Orgegedog Je ne suis pas sûr que ce soit idempotent si vous obtenez une 303 pour la première réponse, puis un 404 pour la seconde. Quelque chose a changé à l'URI.
@ahong Idempotency est une propriété de la transmission, pas l'état! Il n'y a aucune garantie qu'entre deux Mettez des commandes une tierce partie met à jour la ressource à quelque chose de différent. IDÉMPOTENCY GARANTIE QUE CELA D'UN NUMÉRO DE NATIONAL I.E. La demande peut être résolue sans aucune autre considération, car le résultat sera le même pour les deux demandes.
@ahong Idempotence n'a rien à voir avec quelle est la réponse, elle ne concerne que l'état du système. Si vous répétez une demande N fois (et aucun autre changement d'état ne se produit), l'état doit être identique à celui que vous ne l'avez fait qu'une seule fois. Cette réponse satisfait que.
Assez juste sur la réponse. De toutes les réponses que j'ai vues, il semble difficile de trouver un bon moyen de déplacer quelque chose de manière reposante. Voir RFC 7231, section 4.3.3.4 sur mettre a réussi à mettre une représentation donnée suggérerait qu'une solution ultérieure sur cette même ressource cible entraînerait une représentation équivalente envoyée dans une réponse de 200 (OK). Dans ce cas, une entreprise ultérieure reviendrait à 404. Non Dire être reposant est la chose la plus importante, mais si nous le devons, je pense que mettre (copier) et supprimer seraient satisferaient ce qui précède.
@ahong Vous interprétez mal interprété les normes. Ma solution renvoie un statut 303, pas un 2xx, tellement essayant clairement d'obtenir la ressource sur l'URL d'origine est un comportement incorrect.
@Romanvottner a convenu qu'entre 2 puts, autre chose peut arriver. Je suis sûr que nous sommes vraiment d'accord, et peut-être que ce n'est que la sémantique, mais je ne suis pas sûr que ce n'est qu'une propriété de la transmission . Comme il l'étage dans le Définition de l'idempotence d'une méthode HTTP : < I> Une méthode HTTP est idempotent Si une demande identique peut être faite une fois ou plusieurs fois d'une ligne avec le même effet tout en laissant le serveur dans le * même état * . Mettre l'accent sur le mien.
Compte tenu des réponses disponibles, je ne suis pas vraiment satisfaite des propositions.
POST est une méthode tout à fait à utiliser si Aucune des autres opérations ne correspond à la facture. La sémantique d'une charge utile reçue est définie par le service / API uniquement et peut donc une solution pour une API mais pas pour la plupart des autres. Il manque en outre la propriété de l'idempotence qui, dans le cas d'une question de réseau, laissez le client dans une incertitude si la demande reçut le serveur et seule la réponse a été perdue à mi-chemin ou si la demande n'a pas réussi à atteindre le serveur. Une demande consécutive peut donc conduire à des résultats inattendus ou d'actions supplémentaires requises.
Mettre a la sémantique de remplacer le courant Représentation pouvant être obtenue de la ressource (peut être vide) avec la représentation fournie dans la charge utile . Les serveurs sont libres de modifier la représentation reçue à une solution plus appropriée ou à ajouter ou à supprimer d'autres données. On peut utiliser une combinaison de Au lieu d'utiliser les opérations mentionnées ci-dessus, je suggère d'utiliser patch . Mettre peut même avoir des effets secondaires sur d'autres ressources également, c'est-à-dire que si un mécanisme de version de version pour une mise à jour du document est fourni. Tout en fournissant la propriété IDÉMPOTENCE mentionnée ci-dessus, Mettez ne correspond pas à la sémantique de l'action demandée. Cela pourrait avoir de graves conséquences sur l'interopérabilité car les serveurs HTTP standard ne seront pas en mesure de vous servir correctement.
POST pour créer la nouvelle représentation sur le nouveau point d'extrémité d'abord et ensuite, retirez l'ancien via via Supprimer . Toutefois, il s'agit de deux opérations distinctes où la première pourrait échouer et si elle n'est pas traitée correctement entraîner une suppression immédiate de la ressource initiale dans le pire des cas. Il n'y a malheureusement pas de comportement transactionnel réel dans ces opérations.
PATCH est un sérieux de modifications calculées par le client nécessaire pour transformer une représentation actuelle en une desiergeée. Un serveur prenant en charge patch devra appliquer ces instructions atomiquement. Soit tous sont appliqués ou aucun d'entre eux du tout. Patch peut avoir des effets secondaires et est donc l'ajustement le plus approprié pour effectuer un mouvement HTTP actuellement. Pour utiliser correctement cette méthode, cependant, certains types de supports doivent être utilisés. On pourrait orienter sur JSON PATCH ( plus lecteurs respectueux de lecteurs ), c'est-à-dire que cela définit uniquement la sémantique des opérations pour modifier les déclarations basées sur l'état des JSON et ne traite pas de ressources multiples AFAIK.