J'ai lu sur les meilleures pratiques de conception des API pour les services de repos qui seront exposés aux clients. Par exemple, nous devrions utiliser des noms pour nommer toutes les exposées de l'URI. De plus, les verbes doivent obéir à la sémantique des commandes HTTP. Par exemple, une demande d'obtention ne doit jamais modifier la ressource, mais la demande de mise devrait être utilisée ici. On m'a posé cette question lors d'une interview et n'a pas pu répondre à cette question de manière satisfaisante-- Je concevons une calculatrice qui fournit des fonctions suivantes, ajouter, multiplier, diviser, soustraire sur deux opérandes. Comment puis-je exposer ces méthodes aux clients à la suite de principes de repos. Quelle URI à utiliser pour ces opérations? Et je ne suis pas sûr de mapper une opération d'ajout pour obtenir, mettre ou poster. Idem pour les autres opérations (diviser, multiplier, etc.). Quelles sont les lignes directrices ici?
3 Réponses :
Je pense qu'une question avec le terme repos est que cela peut avoir un sens différent pour différentes personnes. Il est possible que l'intervieweur ait une compréhension différente du repos. Lorsque quelque chose comme ça se pose, ma première inclination est d'essayer de comprendre ce que le reste signifie pour eux. Est-ce qu'ils signifient hypermedia? Est-ce qu'ils se soucient des verbes et des noms utilisés correctement comme vous l'avez mentionné? Ou est-ce que dans leur esprit repose juste un point de terminaison HTTP qui retourne JSON. Tous sont possibles.
Je serais enclin à répondre à la question comme suit, je pense:
Quelles sont les lignes directrices ici?
Comment le feriez-vous avec un site Web?
Ce devrait être votre première heuristique à tout moment que quelqu'un vous demande de Reste . Le repos est un
style architectural , conçu pour "de longue durée" applications basées sur des réseaux qui couvrent plusieurs organisations ». L'application de référence pour ce style architectural est le World Wide Web.Je concevons une calculatrice qui fournit des fonctions suivantes, ajouter, multiplier, diviser, soustraire sur deux opérandes. Comment puis-je exposer ces méthodes aux clients suivant les principes de repos.
Il existe trois informations que le client a besoin d'être communiqué au serveur - l'opération et les deux opérandes. Un seul Web, le moyen habituel de collecter ce type d'informations consiste à fournir un formulaire. Dans ce cas, cela pourrait être une liste déroulante des opérations et un couple de contrôles de texte pour accepter des chiffres. Parce qu'une fonction pure est un Safe , nous utiliserions probablement
Obtenez comme méthode de formulaire. Ainsi, les règles de traitement HTML prendraient les valeurs décrites par le formulaire et les transcrivaient en tant que paires de valeur de clé dans la partie de la requête.alors l'URL ressemblerait à quelque chose comme
/ 22520C7F-6207-490e-99c9-bd1bb37f4056? OP = Add & Firstarg = 6 & DeuxiènerG = 9La principale généralisation consiste à réaliser que le formulaire HTML joue le rôle d'un Modèle URI - Le serveur transmet le modèle au client, le client remplit les détails et utilise le résultat comme cible de la demande.
Ce que cela implique est que si vous souhaitiez remplacer HTML avec un autre type de support, vous devez spécifier une description des modèles URI, un mécanisme de décrivant les plages acceptables et quelles valeurs peuvent être des valeurs par défaut raisonnables.
Quelle URI à utiliser pour ces opérations?
avec repos? Absolument n'a pas d'importance. Cela fait partie du point - le client traite URI en tant que valeurs opaques.
URI ne sont que identifiants ; Vous pouvez penser à eux comme des noms de variables dans un programme. Les machines ne se soucient tout simplement pas quelles sont les orthographes (tant que ces orthographes sont compatibles avec la RFC 3986).
Étant donné que l'orthographe n'a pas d'importance, vous pouvez utiliser toutes les conventions d'orthographe locales. Beaucoup de gens favorisent "piratable" URI - l'orthographe de l'identifiant communique des informations utiles au lecteur humain.
URI sont des identificateurs de ressources ; "Toute information qui peut être nommée peut être une ressource". Cela motive certains des «noms non verbes» - les ressources sont des pages Web, des documents, des images ou des scripts, ou ... Le concept «Ressource» est délibérément vague, de sorte qu'il puisse être utilisé de manière flexible. < / p>
Je ne suis pas sûr de ma cartographie d'ajouter une opération pour obtenir, mettre ou poster.
La clé consiste à examiner la sémantique de la demande du client. Chaque fois que vous faites, c'est une requête / une recherche, quelque chose d'ok pour la machine à faire automatiquement pour l'utilisateur, alors vous envisagez une sémantique sécurisée et que la méthode est susceptible d'être obtenez ou de la tête (circonstances particulières).
Si nous demandions au serveur de modifier les représentations de ses propres ressources,
mettre etpost entrez en jeu.Dans ce cas, toutes ces opérations font simplement des recherches, donc
obtenir est approprié.(une chose intéressante à noter, c'est que l'aucune de ces opérations dépend de l'état du serveur; ce sont des fonctions pures. Cela pourrait donc avoir du sens à servir le client avec
code sur demande - JavaScript ou un remplaçant raisonnable - et utilisez le processeur du client pour effectuer les calculs plutôt que de faire un tas de voyages ronds sur le réseau).
Merci beaucoup pour l'explication détaillée.
Autres avec beaucoup plus d'expérience que moi n'avons répondu aux exemples de bonnes façons de le faire.
J'aimerais juste souligner quelle est une très excellente question. Je lis un papier de Richard Taylor et d'autres d'UC Irvine. Richard Taylor était le conseiller de Roy Fielding lorsque le mode de vue décrit se repose dans sa thèse de doctorat. Dans une discussion comparant le repos et le savon, le papier comprend ceci:
"... Plus la sémantique du service est proche de celles du contenu, plus le service est probablement d'avoir une API de repos riche.
...
La division entre le repos et le savon peut refléter un manque de guidage de conception; Comment puis services qui ne sont pas centrés sur le contenu, tels que les enchères enchères ... Soyez proprement construit de manière cohérente? »
Lorsqu'ils disent "plus près du contenu", ils signifient que le service ressemble plus à certaines informations dynamiques ou statiques à récupérer par l'utilisateur final, par opposition à un service ressemble à quelque chose qui effectue activement une fonction ou un calcul pour l'utilisateur. .
Ils continuent de fournir des conseils supplémentaires à ce sujet - mais je n'ai pas encore fini de lire le papier, alors je vous laisserai le regarder pour vous-même. : -)
Rechercher sur le Web pour: des représentations aux calculs: l'évolution de Architectures Web, Richard N. Taylor, UCI