Pourquoi avons-nous besoin de services Web RESTful?

Je vais apprendre les services Web RESTful (il vaut mieux dire que je vais devoir le faire parce que cela fait partie du programme de master CS).

J’ai lu des informations sur Wikipedia et j’ai également lu un article sur REST sur Sun Developer Network et je vois que ce n’est pas une technologie facile, il existe des frameworks spéciaux pour créer des applications RESTful et il est souvent comparé aux services Web SOAP et le programmeur doit comprendre quand utiliser SOAP et quand REST pourrait être une bonne approche.

Je me souviens qu’il y a plusieurs années, SOAP était très populaire (à la mode?) Et que l’article ‘SOAP’ devait être présent dans chaque bon CV. Mais dans la pratique, il était très rarement utilisé et pour atteindre des objectives très simples.

Il me semble que REST est un autre «dernier mot de la mode» (ou je peux totalement me tromper car je n’ai jamais vu REST en pratique).

Pouvez-vous me donner quelques exemples où REST devrait être utilisé et pourquoi nous ne pouvons pas faire la même chose sans REST (ou pourquoi nous devrions passer beaucoup plus de temps à faire la même chose sans REST)?

UPD : Malheureusement, je ne peux pas voir d’argument concret qui puisse me faire peur dans les premiers commentaires. Faites-moi penser que REST est une technologie géniale!

J’aimerais voir des réponses comme ceci:

Je développais une autre application complexe de HelloWorld et nous avons besoin de transférer beaucoup de données / minuscules et j’ai proposé une solution REST à mon collègue:

– Oh putain! Jonny, nous devrions certainement utiliser REST pour implémenter cette application!
– Oui, Billy, on peut utiliser REST, mais il vaut mieux utiliser SOAP. Croyez-moi, je sais quelque chose sur le développement d’applications HelloWorld.
– Mais SOAP est une technologie ancienne du siècle dernier et nous pouvons en utiliser une meilleure.
– Billy, es-tu prêt à passer 3 jours pour expérimenter avec REST? Nous pouvons le faire avec SOAP en 2 heures.
– Oui, je suis sûr que nous passerons encore plus de temps à atteindre la même sécurité / performance / / évolutivité / autre chose avec SOAP. Je suis sûr que les applications HelloWorld doivent être développées uniquement avec REST à partir de maintenant.

REST doit être utilisé s’il est très important pour vous de minimiser le couplage entre les composants client et serveur dans une application dissortingbuée.

Cela peut être le cas si votre serveur va être utilisé par de nombreux clients différents sur lesquels vous n’avez aucun contrôle. Cela peut également être le cas si vous souhaitez pouvoir mettre à jour le serveur régulièrement sans avoir à mettre à jour le logiciel client.

Je peux vous assurer que ce faible niveau de couplage n’est pas facile à faire . Il est essentiel de suivre toutes les contraintes de REST pour réussir. Maintenir une connexion purement sans état est difficile. Choisir les bons types de médias et insérer vos données dans les formats est difficile. Créer vos propres types de médias peut être encore plus difficile.

Adapter le comportement des serveurs riches à une interface HTTP uniforme peut être déroutant et semble parfois pédant par rapport à l’approche RPC relativement simple.

Malgré les difficultés, les avantages sont que vous avez un service qu’un développeur client doit pouvoir comprendre facilement grâce à l’utilisation cohérente du protocole HTTP. Le service doit être facilement détectable en raison de l’hypermédia et le client doit être extrêmement résistant aux changements sur le serveur .

Les avantages de l’hypermédia et la prévention de l’état de session rendent l’équilibrage de charge simple et le partitionnement de service possible . La ssortingcte conformité aux règles HTTP rend la disponibilité des outils tels que les débogueurs et les proxys de mise en cache merveilleux.

Mettre à jour

Il me semble que REST est un autre «dernier mot de la mode» (ou je peux totalement me tromper car je n’ai jamais vu REST en pratique).

Je pense que REST est devenu à la mode parce que les personnes qui tentent de réaliser des projets de type SOA ont découvert qu’en utilisant la stack SOAP, elles ne réalisaient pas les avantages promis. Les gens continuent à revenir sur le Web comme exemple de méthodologies d’intégration simples. Malheureusement, je pense que les gens sous-estiment l’ampleur de la planification et de la prévoyance dans la création du Web et ils simplifient à outrance ce qui doit être fait pour permettre le genre de réutilisation fortuite qui se produit sur le Web.

Vous dites que vous n’avez jamais vu REST dans la pratique, mais cela ne peut pas être vrai si vous utilisez un navigateur Web. Le navigateur Web est un client REST.

  • Pourquoi n’avez-vous pas besoin de faire une mise à jour du navigateur lorsque quelqu’un modifie du code HTML sur un site Web?
  • Pourquoi puis-je append un nouvel ensemble complet de pages à un site Web et le “client” peut toujours accéder à ces nouvelles pages sans mise à jour?
  • Pourquoi n’ai-je pas besoin de fournir un “langage de description de service” au navigateur Web pour lui indiquer quand il ira à http://example.org/images/cat que le type de retour sera une image jpeg et quand vous irez à http://example.org/description/cat le type de retour sera text / html?
  • Pourquoi puis-je utiliser un navigateur Web pour visiter des sites qui n’existaient pas lorsque le navigateur a été publié? Comment le client peut-il connaître ces sites?

Celles-ci peuvent ressembler à des questions obscures, mais si vous connaissez la réponse, vous pouvez commencer à voir en quoi consiste REST. Regardez StackOverflow pour plus d’avantages de REST. Quand je regarde une question, je peux mettre cette page en signet ou envoyer l’URL à un ami et il peut voir les mêmes informations. Il n’a pas à naviguer sur le site pour trouver cette question.

StackOverflow utilise une variété de services OpenId pour l’authentification, gravatar.com pour les images d’avatar, google-analytics et Quantserve pour les informations analytiques. Ce type d’intégration multi-sociétés est le genre de chose dont le monde SOAP ne rêve que . L’un des meilleurs exemples est le fait que les bibliothèques jQuery utilisées pour piloter l’interface utilisateur StackOverflow sont extraites du réseau de dissortingbution de contenu de Google. Le fait que SO puisse demander au client (c.-à-d. Votre navigateur Web) de télécharger du code depuis un site tiers pour améliorer les performances témoigne du faible couplage entre le client Web et le serveur.

Ce sont des exemples d’une architecture REST au travail.

Maintenant, certains sites Web / applications enfreignent les règles de REST et le navigateur ne fonctionne pas comme prévu.

  • Le fameux problème du bouton de retour est dû à l’utilisation de l’état de session côté serveur.
  • L’équilibrage de charge peut devenir difficile lorsque vous avez l’état de session côté serveur.
  • Les applications Flash empêchent souvent l’URL d’identifier spécifiquement une représentation.
  • L’autre problème qui brise les navigateurs Web est la mauvaise conformité aux normes de type de média. Nous entendons tout le temps sur la façon dont IE6 doit être tué. Le problème est que les normes n’ont pas été correctement suivies ou ont été ignorées pour une raison quelconque.
  • L’utilisation de sessions de connexion est la source de nombreuses failles de sécurité.

REST est partout. C’est la partie du Web qui le fait bien fonctionner. Si vous voulez créer des applications dissortingbuées qui peuvent évoluer comme le Web, soyez résilient aux changements tels que le Web et encouragez la réutilisation comme le Web l’a fait, puis suivez les mêmes règles que lors de la création de navigateurs Web.

REST a été lancé, à ma connaissance, par la thèse de Roy Fielding intitulée Architectural Styles et Design of Network-based Software Architectures , qui mérite d’être lue si vous ne l’avez pas regardée.

En haut de la thèse se trouve une citation:

Presque tout le monde se sent en paix avec la nature: écouter les vagues de l’océan contre le rivage, près d’un lac immobile, dans un champ d’herbe, sur une lande soufflée par le vent. Un jour, quand nous aurons appris à nouveau la voie intemporelle, nous ressentirons la même chose dans nos villes, et nous sentirons autant de paix en eux, comme nous le faisons aujourd’hui au bord de l’océan, Prairie.

– Christopher Alexander, le mode de construction intemporel (1979)

Et cela résume vraiment tout cela. REST est à bien des égards plus élégant.

SOAP est un protocole au-dessus de HTTP, il contourne donc de nombreuses conventions HTTP pour créer de nouvelles conventions dans SOAP, et il est de plusieurs manières redondant avec HTTP. HTTP, cependant, est plus que suffisant pour récupérer, rechercher, écrire et supprimer des informations via HTTP, et c’est une grande partie de REST. Étant donné que REST est construit avec HTTP au lieu de cela, cela signifie également que les logiciels qui veulent l’intégrer (comme un navigateur Web) n’ont pas besoin de comprendre SOAP pour le faire, juste HTTP, qui doit être le plus largement compris et intégré – avec protocole utilisé à ce stade.

De là :

Avantages REST:

  • Léger – pas beaucoup de balisage xml supplémentaire
  • Résultats lisibles par l’homme
  • Facile à construire – aucune boîte à outils requirejse

Vérifiez aussi ceci :

Pour être juste, REST n’est pas la meilleure solution pour chaque service Web. Les données devant être sécurisées ne doivent pas être envoyées en tant que parameters dans les URI. Et de grandes quantités de données, comme celles des bons de commande détaillés, peuvent rapidement devenir encombrantes ou même hors limites dans un URI. Dans ces cas, SOAP est en effet une solution solide. Mais il est important d’essayer REST en premier et de ne recourir à SOAP que lorsque cela est nécessaire. Cela permet de garder le développement d’applications simple et accessible.

Je peux dire en toute sécurité que j’ai passé beaucoup de temps à comprendre cela en tant que débutant, mais c’est le meilleur lien pour commencer avec REST à partir de zéro! http://www.codeproject.com/Articles/21174/Tout-About-REST-Web-Services-What-and-How-Pa

Juste pour te ramener,

Pensez à ce qu’est un “service Web traditionnel”. C’est une interface avec des “méthodes” exposées. Les clients connaissent le nom, les entrées et les sorties des méthodes et peuvent donc les appeler.

Imaginez maintenant une interface qui n’expose pas de “méthodes”. Au lieu de cela, il expose des “objects”. Ainsi, lorsqu’un client voit cette interface, tout ce qu’il voit est un ou plusieurs “objects”. “Un object” n’a ni entrée ni sortie – car “il ne fait rien”. C’est un nom, pas un verbe. C’est “une chose”, pas “une action”.

Par exemple, pensez à un service Web traditionnel qui fournit les conditions météorologiques actuelles si vous lui fournissez une ville. Il a probablement une méthode Web comme GetWeatherInfo () qui prend une ville en entrée et fournit des données météorologiques en sortie. Il est facile pour vous de comprendre comment un client va utiliser ce service Web.

Maintenant, imaginez-vous, à la place du service Web ci-dessus, il y en a un nouveau qui expose les villes comme des objects. Ainsi, lorsque vous le regardez en tant que client, au lieu de GetWeatherInfo (), vous voyez New York, Dallas, Los Angeles, Londres, etc. Et ces villes ne disposent d’aucune méthode spécifique à leur application – elles sont apparemment des gaz inertes – elles ne réagissent pas elles-mêmes.

Vous devez penser – eh bien, comment cela vous aide-t-il, en tant que client, à aller à la météo de Dallas? Nous y reviendrons dans quelques instants.

Si tout ce que vous obtenez d’un service Web est un “ensemble d’objects”, vous avez évidemment besoin d’un moyen pour “agir sur eux”. Les objects eux-mêmes n’ont aucune méthode à appeler, vous avez donc besoin d’un ensemble d’actions que vous pouvez appliquer sur ces objects. En d’autres termes, vous devez “appliquer un verbe au nom”. Si vous voyez un object, par exemple une pomme, qui est “un nom”, vous pouvez lui appliquer “un verbe” comme manger. Mais tous les verbes ne peuvent pas être appliqués à tous les noms. Comme, vous pouvez conduire une voiture, mais ne pouvez pas conduire une télévision.

Ainsi, si un service Web n’expose que des objects, et vous êtes invité – eh bien, laissez-nous maintenant concevoir quelques actions ou verbes standard que “tous les clients peuvent appliquer à tous les objects qu’ils voient”, …

La plupart des réponses “pro” à propos de REST semblent provenir de personnes qui n’ont jamais développé de service Web ou de client SOAP en utilisant un environnement qui fournit des outils appropriés pour la tâche. Ils se plaignent de problèmes que je n’ai jamais rencontrés, à l’aide de Visual Studio .NET et de Rational Web Developer d’IBM. Je suppose que si vous devez développer des services Web ou des clients dans un langage de script ou dans une autre langue avec peu ou pas de prise en charge d’outils, il s’agit de plaintes valides.

Je dois également admettre que plusieurs des points “pro” ressemblent à des choses qui pourraient être vraies – mais que je n’ai jamais vu un exemple qui illustre leur valeur. En particulier, j’apprécierais beaucoup que quelqu’un publie un commentaire contenant un lien vers un bon exemple de service Web REST. Cela devrait être celui qui utilise plusieurs niveaux de ressource, éventuellement dans une hiérarchie, et qui utilise correctement les types de média. Peut-être que si je regarde un bon exemple, je comprendrai, auquel cas je reviendrai ici et l’admettrai.

Pour append un tour légèrement prosaïque aux réponses déjà fournies, la raison pour laquelle nous utilisons les services REST où je suis, c’est que si vous savez que vous pouvez envoyer une URL à un partenaire et savoir qu’il recevra en retour une dalle XML bien présentée peu importe qu’ils travaillent dans .Net xx, PHP, Python, Java, Ruby ou dieu sait ce qui réduit considérablement les maux de tête.

Cela signifie également que, du sharepoint vue de la technologie, nos commerciaux peuvent se vanter de notre API polyvalente pour les personnes qui ne craignent pas de ressembler à des muppets complets.

Mis à part les avantages techniques, tout ce qui est facile pour un non-technicien à expliquer, démontrer et avoir confiance en lui est une bonne chose. SOAP, bien que tout aussi cool pour les techniciens, est beaucoup moins accessible aux non-techniciens et n’est donc pas aussi facile à “vendre”.

J’ai tendance à remarquer que les choses que les non-techniciens peuvent avoir en tête tendent à coller. Je doute donc que REST soit une technique susceptible d’être aussi sensible que SOAP aux caprices de la mode.

Mais tout ce qui concerne le fait de ne rien mettre dans un service REST qui devrait être verrouillé est double, ne serait-ce que parce que la technologie est si facilement comprise par les personnes qui ne sont pas très au fait des techniques.

Voici quelques idées:

  • REST limite votre service à utiliser une interface uniforme. Vous n’avez pas à perdre votre temps à rêver (ou à vous disputer) de toutes les façons dont votre service pourrait fonctionner – vous avez tout intérêt à identifier les ressources de votre système. Se révèle être un gros travail en soi, mais heureusement, les problèmes ont tendance à être mieux définis.
  • Avec des ressources, leurs associations et leurs représentations en main, il y a vraiment peu à faire dans la mise en œuvre de votre service, car de nombreuses décisions ont été sockets pour vous.
  • Votre système ressemblera beaucoup aux autres systèmes RESTful. Les courbes d’apprentissage pour les coéquipiers, les partenaires et les clients seront réduites.
  • Vous aurez un vocabulaire commun pour discuter des problèmes de conception avec d’autres développeurs, et même avec ceux qui ont moins de connaissances techniques (comme les clients).
  • Comme le dit Darrel, parce que vous utilisez une conception basée sur l’hypertexte , votre service restreint la scope du couplage à une seule chose: les types de supports. Cela vous aide en tant que développeur car les modifications apscopes à votre système sont contenues dans une bande de contact étroite. Cela aide vos clients à réduire le nombre de modifications apscopes à leur code.
  • Presque tous les problèmes que vous pourriez avoir dans l’implémentation de REST peuvent être résolus en exposant une nouvelle ressource ou en repensant votre modèle de ressource. Cet objective est, à l’OMI, un gros gain de productivité.

En bout de ligne, REST supprime un grand nombre des décisions de conception et de mise en œuvre les plus chronophages et les plus délicates du stream de travail de votre équipe. Cela détourne votre attention de la mise en œuvre de votre service à la conception . Et cela sans emstackr gobbledygook sur le protocole HTTP.

REST est un style d’architecture pour la conception d’applications en réseau. L’idée est que, plutôt que d’utiliser des mécanismes complexes tels que CORBA, RPC ou SOAP pour se connecter entre machines, HTTP simple est utilisé pour passer des appels entre les machines.

À bien des égards, le World Wide Web lui-même, basé sur HTTP, peut être considéré comme une architecture basée sur REST. Les applications RESTful utilisent les requêtes HTTP pour publier des données (créer et / ou mettre à jour), lire des données (par exemple, effectuer des requêtes) et supprimer des données. Ainsi, REST utilise HTTP pour les quatre opérations CRUD (Create / Read / Update / Delete).

REST est une alternative légère aux mécanismes tels que RPC (Remote Procedure Calls) et Web Services (SOAP, WSDL, et al.). Plus tard, nous verrons à quel point REST est plus simple.

En dépit d’être simple, REST est entièrement équipé; Il n’y a pratiquement rien que vous puissiez faire dans les services Web qui ne peuvent pas être réalisés avec une architecture RESTful. REST n’est pas un “standard”. Par exemple, il n’y aura jamais de recommandation du W3C pour REST. Et bien qu’il existe des frameworks de programmation REST, travailler avec REST est si simple que vous pouvez souvent «rouler» avec des fonctionnalités de bibliothèque standard dans des langages tels que Perl, Java ou C #.