Je cherche une bonne URL, à la suite de principes de repos, à "déplacer le concurrent de Team1 vers To Team2
mon premier devin est: mais ne ressemble pas beaucoup à vous reposer. devrais-je le casser en 2 appels de base? Dois-je supprimer certaines données de l'URL et le transmettre dans le corps? Je ne sais pas vraiment quoi faire pour celui-ci.
3 Réponses :
Pensez à la manière dont vous impliqueriez cette API en tant que site Web.
Vous auriez probablement un lien vers une forme - cela pourrait être un formulaire où le concurrent, l'ancienne équipe et la nouvelle équipe sont toutes vierges, ou Cela pourrait être une forme où le concurrent et la vieille équipe sont pré-peuplés. Votre consommateur met à jour les informations par défaut dans le formulaire selon les besoins et le soumet.
Notez le premier point (soulevé par le votteur romain aussi) - Votre consommateur n'a pas besoin de regarder l'URL du tout . Le client connaît les règles de traitement de formulaire HTML, il peut donc créer la demande HTTP correcte sans rien savoir sur le domaine.
Le deuxième point est que, puisque le client ne soumet que le formulaire à l'autre que le HTML raconte Pour, vous pouvez faire ce que tout ce que vous voulez.
Une des propriétés intéressantes de HTTP est une invalidation de cache. Voir RFC 7234 , toute réponse non erronée à une demande dangereuse invalidera tous les mises en cache représentations d'une ressource.
afin que vous puissiez choisir quelle ressource est invalidée en spécifiant son URI comme cible du formulaire. En effet, cela vous donne un mécanisme permettant de veiller à ce qu'un consommateur puisse lire ses propres écrivies.
de sorte que certains choix raisonnables pour la cible pourraient être Si la liste des équipes est la chose la plus importante. Ou si la ressource décrivant le lecteur est ce qui est le plus important. Je ne sais pas vraiment quoi faire pour celui-ci.
Concentré pour faciliter l'utilisation. Votre modèle de ressource n'est pas votre modèle de domaine n'est pas votre modèle de données. Il sera probablement utile de regarder la conversation de Jim Webber RESTE: DDD dans le grand pour obtenir des informations plus claires sur ce que votre API de" repos "devrait vraiment ressembler.
Pour répondre à vos questions, je ne les briserais pas en deux appels, je prendrais cependant des données de cette URL (obtenez) et de la mettre dans le corps de votre demande. La demande serait probablement un poste ou mis (ou peut-être même un patch), mais certainement pas un get depuis que quelque chose change effectivement.
Quant à une solution, que diriez-vous d'une requête postale à un / transfert. Après tout, vous êtes (pourrait être) créer un nouveau transfert qui prend par exemple le joueur, leur nouvelle équipe et peut-être leur ancienne équipe.
J'utiliserais l'URL pour identifier la ressource qui, dans ce cas, semble être une équipe du concurrent.
alors serait
/ concurrents / {concurrentiel} / équipes
- Faites appel à l'appel
Mettez
- Avoir un corps avec Newteamid et si requis l'Oldteamid.
Le reste ne se soucie pas de la façon dont vous définissez votre URI car les clients ne doivent pas compter sur l'analyse ou l'interpréter. Au lieu de cela, vous devez définir et utiliser des noms de relation de liaison significatifs, de négociation de contenu et de formats de documents normalisés pour échanger des messages. Cela permet fondamentalement au serveur de changer et d'évoluer sans affecter négativement les clients. Si vous n'avez pas besoin de telles propriétés, ne visez pas au repos pour commencer.