Donc, j'ai actuellement une application qui appelle un service Web pour récupérer des données, où je fais un HTTP de base, obtenez une URL comme www.example.com/service.asmx?param1=1¶m2=2 Cela renvoie quelques XML que je pars.
Ma question est que cela classait-il un service Web reposant? Je pense que non, mais j'aimerais savoir ce qui en fait un service Web de repos?
Je sais qu'il y a des services Web de repos et de savon, mais qu'est-ce que le cas ci-dessus sera classé comme un service Web simple HTTP? ou quelque chose?
Merci, j'essaie de faire correspondre la terminologie aux concepts, pardonnez-moi si cela est un peu trop élémentaire.
5 Réponses :
Les services de repos sont ces services qui sont généralement conformes aux éléments suivants:
La raison pour laquelle votre URL n'est pas aussi "reposante", car il pourrait être qu'il contient des informations non identifiantes (telles que .asmx). De plus, certains pensent que l'ajout de paramètres d'URL n'est approprié que pour le filtrage. (Mais cela ne signifie pas que l'utilisation des paramètres d'URL n'est pas reposante!)
S'il semble qu'il n'y ait pas de règles difficiles et rapides, vous êtes sur la bonne voie.
Des services souvent reposants sur XML, cependant, ce n'est aucune règle difficile par aucun moyen non plus.
Ceci est une erreur. Le repos est une architecture formellement définie. Non où dans sa spécification, il mentionne HTTP. En outre, la contrainte apatride est absolue, pas seulement «minimale». L'identifiant lui-même ne décrit pas la ressource - URIS peut être représenté mais vous le souhaitez. Le type de support de la ressource n'est décrit que dans l'API. Obtenez / post / Publier / Supprimer Utilisation n'a rien à voir avec le repos - il s'agit simplement d'une utilisation http appropriée. "URL reposant" est un concept inexistant. Il y a des règles difficiles et rapides pour se reposer. Si vous violez les contraintes de repos, votre API n'est tout simplement pas de repos et ne doit pas être appelée comme telle.
Je pense que vous auriez de la difficulté à tirer un lien vers une définition officielle de l'architecture (c.-à-d. Une spécification). Le mieux que vous trouverez est le thème original par le champ: ics.udu.edu/~fielding/pubs/dissertation/top.htm - qui, est utile et spécifique pour un académique, mais n'est pas une spécification formelle. Il y a ce que le champ défini et repose dans la pratique.
Non, il y a ce que définit le domaine défini et mille interprétations erronées. Cette idée que vous pouvez mettre en œuvre certaines des contraintes, puis prétendre que c'est "repos en pratique" est des conneries. Pour affirmer que la thèse de ce fusion n'est pas une spécification formelle est folle. Ce n'est pas parce qu'il ne définit pas une architecture ou une mise en œuvre spécifique ne le rend pas imprécis.
Reposez-vous dans la pratique qui ne se conforme pas aux contraintes du champ comme détaillées dans sa thèse ne se repose tout simplement pas. Bien sûr, il y a des développeurs qui ne comprennent pas le repos et abusent de la peine - ce n'est pas une excuse pour propager des inexactitudes. Il existe de réels avantages pour comprendre le repos et suivre ses contraintes. Le champ n'est pas perdu dans les universités, loin de la réalité - il a non seulement participé à la construction HTTP, mais il est également actuellement employé à Apache.
En fait, je crois qu'il est employé par un logiciel de jour, mais il participe activement à la Fondation Software Apache. Bien sûr, il dépense son temps à travailler sur de vrais produits pour de vrais clients. Certainement pas coincé dans les universités.
Je vais accepter que les contraintes de style architectural apportent des avantages réels. Il y a une raison que certains services sont appelés plus reposants que d'autres. Je suis sûr que vous considérez que les deux considèrent comme une abomination aussi, mais cela reflète plus précisément la réalité: la rencontre de chaque ligne directrice du repos est difficile, et je me fatigue rapidement d'astronautes architecturaux qui essaient de forcer des mises en œuvre coûteuses et fastidieuses pour la pureté de repos .
Quelles contraintes en particulier vous sentez-vous inutiles? Quoi qu'il en soit, nous ne préconisons pas le repos pour chaque application, juste la bonne utilisation du terme. J'ai l'impression que ce sont ceux qui ne comprennent pas le repos qui essaie de le pousser à chaque service.
Premièrement, laissez-moi vous assurer que j'écris du vrai code qui est livré à de vrais clients, en utilisant régulièrement une architecture reposante. La réalité est que le repos n'est pas juste pour toutes les situations. Il y a beaucoup d'alternatives. Ce que je suis pneus, c'est que les gens utilisent le terme reposent lorsque des contraintes sont violées. N'hésitez pas à mettre en œuvre vos services distribués à l'aide de XML sur HTTP, n'appelez tout simplement pas le repos. Abuser du terme conduit à la confusion que nous voyons ici tout le temps au débordement de la pile. Les gens ne peuvent pas dire ce qui est le repos et ce qui n'est pas parce que tout le monde appelle tout ce qui utilise HTTP et un repos d'URL.
Eh bien, c'est limitrophe sur Pedantic, et revient vraiment à mon point que le repos a perdu son sens original. Ce qui ne devrait être pas une grosse surprise, cela fait presque une décennie depuis la mémoire de la thèse et était essentiellement «perdue» comme un «style architectural» jusqu'à récemment. Mais, honnêtement, j'apprécie toujours les liens vers les rénovations des réfractions récentes sur le sujet +1 à votre réponse. Temps pour moi d'aller pour la journée cependant, bonne chance.
Cela fait encore plus longtemps que la spécification HTTP a été écrite et cela semble avoir fallu jusqu'à présent pour que la plupart des gens commencent à se soucier de tout ce qu'il offre, par ex. Utilisation correcte de ses verbes, des uRis propres et descriptives, etc. En d'autres termes, ce que beaucoup de gens se confondent pour le repos.
Vous pensez que cela est en train d'être pédants, allez chercher des discussions sur la gamme http-gamme 14. Way Smarter Personnes que moi nous disputons depuis des années sur quelle ressource Web est et si HTTP peut indiquer des voitures et des chiens ou non?
Une réponse directe à votre question est je ne sais pas . Le repos est un style architectural (pas une technique de conception ou de mise en œuvre), cela signifie que vous devez suivre ses principes dans l'architecture de votre logiciel pour l'obtenir classée comme reposante:
la source n ° 1 que vous devez consulter avant tout faire de manière reposante est le Thèse de doctorat de Roy Fielding ," le gars qui a inventé le repos ": -)
Notez que le repos ne spécifie pas les schémas d'URL, mais il y a des les meilleures pratiques à propos des systèmes d'URL dans des architectures reposantes, comme
Les informations que vous avez fournies sur votre service Web ne sont pas suffisamment précises pour l'obtenir classées comme service Web reposant.
Les schémas de nommage d'Uri n'ont rien à voir avec le repos. Votre PDF lié n'est pas basé sur des sources faisant autorité et n'est pas une représentation précise du repos - repos ne concerne pas CRUD, pour une. Une demande d'obtention avec les paramètres n'a rien à voir avec le repos - il n'est que http, ce qui ne fait pas partie de la spécification de l'architecture de repos.
Downvote pour une réponse correcte (le reste ne spécifie pas comment une réponse d'obtention doit être effectuée) et un PDF sur les meilleures pratiques? Est-ce que ça a du sens?
L'article est uniquement à propos de HTTP, il ne parle pas réellement de concepts de repos, sauf pour appeler par erreur.
Juste parce que le reste ne précise pas quelque chose ne signifie pas que cela est considéré comme reposant.
Si cela ne violera aucune règle de repos, pourquoi ne peut-il pas être considéré comme reposant?
Le reste ne précise rien des lecteurs CDDOM - Est-ce que cela rend mon ordinateur reposant? ... Le repos inclut un ensemble de contraintes qui doivent être suivies. Si vous ne remplissez pas ces contraintes, ce n'est pas du repos. Utiliser simplement GET n'est pas suffisant pour satisfaire les contraintes.
J'apprends de nouveaux concepts tous les jours ... répondez entièrement réécrit :-)
Merci, content que vous pensiez y avoir examiné, même si ce n'est pas une réponse très utile et s'il vous plaît, n'habitez pas beaucoup d'emphase: D
Je ne pense pas que vous obtiendrez une réponse définitive à ce sujet. Les services de repos et de site Web sont des termes très déroutants, maintenant vous les combinez ensemble.
Le reste pourrait signifier,
Les services Web ont également plusieurs significations,
Le repos n'a rien à voir avec les conventions d'urui nommant ou http. Vous avez un "repos" pour "http" dans vos points. L'orthographe du repos est hors de propos, et Roy Fielding lui-même l'écrit de toute façon.
La seule raison que ces problèmes sont confuses, c'est que quelque part au cours des dernières années, le repos est devenu un nouveau mot à buzz et tous les vendeurs ont commencé à convertir leurs cadres en repos "Support" et les sites Web 2.0 ont commencé à faire des API qu'ils étions qualifiées de "repos" parce qu'il était synonyme de "simple et facile". Malheureusement, la majorité de ces implémentations n'ont pas permis de saisir le point de repos et de le faire avoir vraiment confondu beaucoup de gens. La première API publique majeure qui a vraiment eu est l'API du nuage Sun Cloud. Netflix n'est pas trop loin non plus.
Il continue également de se propager par les équipes marketing qui ressentent l'étiquetage de leur API "REST" le rendra plus attrayant pour les développeurs. Voir Flickr's, qui ne repose pas du tout, et je suis sûr que quelqu'un le sait.
Ceci a été répondu à plusieurs reprises avant sur ce site. Vous devriez jeter un coup d'œil à DISERTATION DE FICHIERS pour l'autorité source sur le repos. Son blog a également des postes utiles.
La représentation de l'URI n'a rien à voir avec le repos, mais en regardant le vôtre, on dirait que votre service est probablement RPC plutôt que de se reposer. Si vous n'avez qu'une seule URI pour l'ensemble du service, que vous apportez des appels vers des paramètres ou des en-têtes de la requête, c'est RPC, semblable au savon.
Le concept de repos le plus important est que vos ressources sont découvertes et naviguées par hypertexte. Votre API doit être une description de vos types de médias. Le seul, unique URI de votre API est le point d'entrée.
La réponse directe à votre question est non.
décomposer ce que vous nous avez dit de votre service, je vais discuter de ce qui est un n'est pas reposant sur votre solution.
http obtenir sur une url comme si tellement www.example.com/service.asmx?param1=1¶m2=2
Vous utilisez un get HTTP et utilisez donc l'un des verbes limités pour accéder à une sorte de ressource via une URI. Ceci est reposant et conforme à la contrainte d'interface uniforme tant que le serveur ne viole aucune des règles HTTP sur ce que l'on veut faire.
En regardant l'URL elle-même, il n'est pas évident de savoir quelle ressource vous accédez et cela indique donc que votre espace URL peut ne pas être structuré d'une manière qui convient parfaitement à une conception reposante. Cependant, le reste ne met aucune contrainte sur ce que votre URL devrait ressembler (malgré ce que Soooooooo beaucoup de gens pensent), donc il n'y a rien de trouble avec votre URL.
Ceci renvoie certains XML que je pars.
Voici où vos problèmes commencent. Ce que je lis implicitement dans cette déclaration, c'est que le client sait analyser les données de votre XML. Ceci est une violation de la contrainte d'auto-descriptive du repos. Le message HTTP doit contenir toutes les informations nécessaires au client de savoir comment traiter la réponse d'une demande. Le type multimédia doit indiquer au client quelles informations sont dans le document XML. Si votre service renvoie Application / XML, la seule chose que le client sait que le document contient des attributs et des éléments. Si le client utilise des connaissances hors bande pour analyser que XML, vous introduisez un couplage entre le client et le serveur. L'un des objectifs majeurs du repos est d'éliminer ce couplage.
Il existe un certain nombre d'autres contraintes qu'un service doit respecter pour être considéré comme reposant, mais vous ne fournissez pas suffisamment de détails sur votre service pour dire d'une manière ou d'une autre si elle est conforme.
- Comment créer un service Web reposant pouvant répondre à un client de manière non couplée? est supposé que le client est capable de traiter la réponse; Ne nous exhorte-t-il pas à structurer la ressource sous une forme concrète?
- "Il existe un certain nombre d'autres contraintes qu'un service doit respecter afin d'être considéré comme reposant" - où puis-je trouver ces contraintes indiquées?
@John Je ne pense pas que ce soit un duplicata du reste du débat sur le savon. J'interprète la question comme ce qui est ou n'est pas reposant sur la solution proposée. Je crois que c'est une question beaucoup plus valable. Vous avez peut-être raison de dire qu'il s'agit d'un duplicata, mais ce n'est pas un duplicata de repos par rapport au savon.