Pourquoi avons-nous besoin de services Web RESTful?


123

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

J'ai lu des informations sur Wikipédia 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 cadres 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 peut être une bonne approche.

Je me souviens qu'il y a plusieurs années, SOAP était très populaire (à la mode?) Et l'élément «SOAP» devait être présent dans tout bon CV. Mais dans la pratique, il a été utilisé très rarement et pour atteindre des objectifs très simples.

Il me semble que REST est un autre «dernier mot de la mode» (ou je peux 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 de même sans REST (ou pourquoi nous devrions passer beaucoup plus de temps à faire de même sans REST)?

UPD : Malheureusement, je ne vois pas d'arguments concrets qui peuvent me surprendre dans les premiers commentaires. Faites-moi penser que REST est une technologie géniale!

J'aimerais voir des réponses comme celle-ci:

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

- Oh putain! Jonny, nous devrions certainement utiliser REST pour implémenter cette application!
- Oui, Billy, nous pouvons utiliser REST, mais nous ferions mieux d'utiliser SOAP. Croyez-moi car je sais quelque chose sur le développement d'applications HelloWorld.
- Mais SOAP est une technologie démodée du siècle dernier et nous pouvons en utiliser une meilleure.
- Billy, êtes-vous prêt à passer 3 jours à expérimenter 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é / quoi que ce soit d'autre avec SOAP. Je suis sûr que les applications HelloWorld devraient être développées uniquement avec REST à partir de maintenant.


2
Ce n'est pas une technologie géniale - c'est une technologie différente. Si vous voulez que quelqu'un vous convainc que c'est génial et doit être utilisé à chaque fois, essayez un consultant.
quillbreaker

Réponses:


133

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 distribuée.

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

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

L'adaptation d'un comportement de serveur riche dans l'interface HTTP uniforme peut être déroutante et parfois semble pédante par rapport à l'approche RPC relativement simple.

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

Les avantages de l'hypermédia et le fait d'éviter l'état de session rendent l'équilibrage de charge simple et le partitionnement des services faisable . La stricte conformité aux règles HTTP rend la disponibilité d'outils comme les débogueurs et les proxys de mise en cache une chose merveilleuse.

Mettre à jour

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

Je pense que REST est devenu à la mode parce que les gens qui tentent de faire des projets de type SOA ont constaté qu'en utilisant la pile SOAP, ils ne réalisaient pas les avantages promis. Les gens continuent de se tourner vers le Web comme exemple de méthodologies d'intégration simples. Malheureusement, je pense que les gens sous-estiment la quantité de planification et de prévoyance nécessaire à la création du Web et ils simplifient à l'extrême ce qui doit être fait pour permettre le type 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 ajouter un nouvel ensemble complet de pages à un site Web et que 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 dire lorsqu'il accède à http://example.org/images/cat que le type de retour sera une image jpeg et quand vous y allez à 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 au moment de la sortie du navigateur? Comment le client peut-il connaître ces sites?

Celles-ci peuvent sembler stupides, mais si vous connaissez la réponse, vous pouvez commencer à voir en quoi consiste REST. Regardez StackOverflow pour plus d'avantages de REST. Lorsque je regarde une question, je peux ajouter cette page à mes favoris ou envoyer l'URL à un ami et il peut voir les mêmes informations. Il n'a pas besoin de 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-entreprises est le type 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 gérer l'interface utilisateur StackOverflow sont extraites du réseau de diffusion de contenu de Google. Le fait que SO puisse diriger le client (c'est-à-dire votre navigateur Web) pour télécharger du code à partir d'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'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 tristement célèbre problème de bouton retour est causé par l'utilisation de l'état de session côté serveur.
  • L'équilibrage de charge peut devenir un problème lorsque vous avez un é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 constamment dire comment IE6 doit être tué. Le problème, c'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 à l'origine de nombreuses failles de sécurité.

REST est partout. C'est la partie du Web qui le fait bien fonctionner. Si vous souhaitez créer des applications distribuées qui peuvent évoluer comme le Web, être résilient au changement comme le Web et promouvoir 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.


@Darrell: comment REST réduit-il le couplage par rapport au SOAP? Ou, comment SOAP augmente-t-il le couplage par rapport à REST? Faites-vous référence au fait qu'un client SOAP a réellement besoin de comprendre SOAP, mais qu'un client REST n'a besoin que de comprendre les types de médias?
John Saunders le

4
@John Généralement, la façon dont SOAP est utilisé oblige le client à exiger une connaissance "compilée" de chaque point de terminaison côté serveur, de chaque type de données de paramètre et de chaque type de retour. Il n'y a aucune directive dans le monde SOAP pour essayer d'utiliser des types standardisés pour transmettre des données entre le client et le serveur. Cela signifie que chaque nouveau service qu'un développeur client utilise possède son propre ensemble unique de types, de points de terminaison et de protocole d'interaction. C'est le couplage.
Darrel Miller le

@John REST tente de standardiser le protocole d'interaction à la sémantique des verbes HTTP, les formats de données des types enregistrés IANA et tous les points de terminaison doivent être détectables de manière dynamique. Cela signifie que le couplage client / serveur est localisé à la définition du type de média. Tout comme Rich l'a dit, "votre service réduit la portée du couplage à une seule chose - les types de médias."
Darrel Miller

@Darrell: ce n'est pas un couplage au sens traditionnel du terme. Le client peut être considéré comme «couplé» aux métadonnées (le WSDL), mais pas au service. Considérons un service qui renvoie un "Employé": {int id; string firstName, lastName, streetAddress1, streetAddress2, city, state; int zip;}. Vous semblez suggérer soit que nous enregistrions «Employé» auprès de l'IANA, soit que nous considérions simplement «Employé» comme un tableau associatif de paires nom / valeur.
John Saunders

@John Permettez-moi de définir ce que j'entends par couplage en termes WSDL. Imaginez pouvoir avoir un contrat de service auquel vous pourriez ajouter des méthodes, supprimer des méthodes et renommer des méthodes sans avoir à recompiler le client. Considérez également que le client pourrait être invité à utiliser ces nouvelles méthodes sans recompilation. Le contrat de message est fixé par HTTP mais il est extensible via des en-têtes et le contrat de données est le seul changement qui pourrait briser un client, mais en utilisant des métadonnées dans le contrat de message, le serveur pourrait fournir dynamiquement une version appropriée du contrat de données au client.
Darrel Miller

11

REST a été lancé, à ma connaissance, par la thèse de Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures , qui vaut la peine 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, au bord d'un lac immobile, dans un champ d'herbe, sur une lande balayée par le vent. Un jour, quand nous aurons appris à nouveau la voie intemporelle, nous ressentirons la même chose à propos de nos villes, et nous nous sentirons aussi en paix en eux, que nous le faisons aujourd'hui en marchant au bord de l'océan, ou allongés dans les hautes herbes d'un Prairie.

- Christopher Alexander, La manière intemporelle de construire (1979)

Et cela résume vraiment la situation. 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 est à bien des égards redondant avec HTTP. HTTP, cependant, est plus que suffisant pour récupérer, rechercher, écrire et supprimer des informations via HTTP, et c'est en grande partie ce qu'est REST. Étant donné que REST est construit avec HTTP plutôt que par dessus, cela signifie également que les logiciels qui souhaitent s'y 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é au protocole utilisé à ce stade.


SOAP a été défini en 1998. Combien de "conventions" HTTP étaient des conventions à l'époque?
John Saunders le

Selon ce w3.org/Protocols/HTTP/1.0/spec.html HTTP est utilisé depuis 1990. Et alors? Nous savons tous que la seule raison pour laquelle SOAP utilise http était parce que le port 80 était le plus susceptible d'être ouvert sur le pare-feu. Microsoft n'allait pas refaire l'erreur DCOM.
Darrel Miller

1
" REST est construit avec HTTP au lieu de dessus " +1. Ce fil de discussion est vraiment utile pour moi pour comprendre la validité de l'utilisation de REST sur SOAP et vice versa.
Chris22

9

D' ici :

Avantages REST:

  • Léger - pas beaucoup de balisage XML supplémentaire
  • Résultats lisibles par l'homme
  • Facile à construire - aucune boîte à outils requise

Vérifiez également ceci :

Pour être honnête, REST n'est pas la meilleure solution pour chaque service Web. Les données qui doivent être sécurisées ne doivent pas être envoyées en tant que paramètres 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 d'abord REST et de recourir à SOAP uniquement lorsque cela est nécessaire. Cela permet de garder le développement d'applications simple et accessible.


4
Le contre-commentaire n'est pas très correct. En déplaçant un paramètre de l'URI dans le corps, cela n'est toujours pas sécurisé. Utilisez SSL pour la sécurité. De plus, lorsque les données de l'URI peuvent être très longues, vous êtes autorisé à utiliser post et à le mettre dans le corps. La plupart des langages côté serveur combinent les données des paramètres URI et POST, donc aucune modification sur le serveur ne devrait être nécessaire.
Emil Ivanov le

1
@Emil - Gardez à l'esprit que SSL n'est pas toujours disponible. Certaines personnes veulent une sécurité basée sur les messages et non une sécurité basée sur le niveau de transport. Et en ce qui concerne l'utilisation du corps d'un POST ... POST est l'un des verbes utilisés pour traiter les requêtes REST. Vous ne pouvez pas toujours le réutiliser pour répondre à vos besoins.
Justin Niessner le

1
Un gros inconvénient: pas de langage de "description" standardisé comme WSDL pour les services SOAP - chaque service REST peut ou non être documenté, et la qualité de la documentation est très différente d'une offre de service à l'autre .....
marc_s

3
@Marc_s Si REST est fait correctement, il n'y a pas besoin d'un "langage de description" comme WSDL. Les types de supports utilisés doivent être documentés, mais il ne devrait pas exister de documentation qui couple les points de terminaison aux types de supports.
Darrel Miller le

@Darrel: Je suis désolé, je n'achète pas le non-sens "sans langage de description". Même si les types de documents sont documentés, ils doivent également être décrits. De plus, certaines personnes aiment désérialiser le contenu en objets dans un langage de programmation. Dans ce cas, il est très utile d'avoir une définition lisible par machine de ce que le service peut envoyer et recevoir, afin que votre outil puisse créer les classes correspondantes et le code de sérialisation.
John Saunders

8

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/Everything-About-REST-Web-Services-What-and-How-Pa

Juste pour vous attirer,

Pensez à ce qu'est un "service Web traditionnel". C'est une interface avec des «méthodes» exposées. Les clients connaissent le nom, l'entrée et la sortie 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 «objets». Ainsi, lorsqu'un client voit cette interface, il ne voit qu'un ou plusieurs "objets". "Un objet" 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. Jusqu'à présent, il vous est facile de comprendre comment un client consommera ce service Web.

Imaginez maintenant, à la place du service web ci-dessus, qu'il y en ait un nouveau qui expose les villes comme des objets. Ainsi, lorsque vous le considérez comme un client, au lieu de GetWeatherInfo (), vous voyez New York, Dallas, Los Angeles, Londres et ainsi de suite. Et ces villes n'ont pas de méthodes spécifiques d'application qui leur sont suspendues - elles sont apparemment comme des gaz inertes - elles-mêmes ne réagissent pas.

Vous devez penser - eh bien, en quoi cela vous aide-t-il, en tant que client, à connaître 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'objets", vous avez évidemment besoin d'un moyen "d'agir sur eux". Les objets eux-mêmes n'ont aucune méthode à appeler, vous avez donc besoin d'un ensemble d'actions que vous pouvez appliquer à ces objets. En d'autres termes, vous devez "appliquer un verbe au nom". Si vous voyez un objet, disons, 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. Par exemple, vous pouvez conduire une voiture, mais pas une télévision.

Ainsi, si un service Web n'expose que des objets, et qu'on vous le demande - eh bien, concevons maintenant quelques actions ou verbes standards que "tous les clients peuvent appliquer à tous les objets qu'ils voient", ...


Alors quel est l'avantage d'avoir un objet plutôt qu'une méthode?
Soumya Rauth

4

Voici quelques idées:

  • REST contraint votre service à utiliser une interface uniforme. Vous n'avez pas à perdre de temps à rêver (ou à vous disputer) sur toutes les façons dont votre service pourrait fonctionner - vous avez le droit de travailler en identifiant les ressources de votre système. Cela s'avère être un gros travail en soi, mais heureusement, les problèmes ont tendance à être beaucoup mieux définis.
  • Avec les ressources, leurs associations et leurs représentations en main, il n'y a vraiment pas grand-chose à faire dans la mise en œuvre de votre service car de nombreuses décisions ont été prises 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 d'esprit technique (comme les clients).
  • Comme le dit Darrel, comme vous utilisez une conception basée sur l'hypertexte , votre service réduit la portée du couplage à une seule chose: les types de médias. Cela vous aide en tant que développeur car les modifications apportées à votre système sont contenues dans une bande étroite de contacts. Cela aide vos clients à réduire le nombre de vos modifications qui briseront leur code.
  • Presque tous les problèmes que vous pourriez rencontrer lors de la mise en œuvre de REST peuvent être résolus en exposant une nouvelle ressource ou en repensant votre modèle de ressource. Cet objectif est, à l'OMI, une grande augmentation de la productivité.

En fin de compte, REST supprime la plupart des décisions de conception et de mise en œuvre les plus longues et les plus controversées du flux de travail de votre équipe. Cela déplace votre attention de la mise en œuvre de votre service à sa conception . Et il le fait sans empiler gobbledygook sur le protocole HTTP.


@John Si je lance VS et crée un projet WCF et crée une interface avec l'attribut [ServiceContract], je peux ajouter tous les appels de méthode que j'aime. CreateCustomer (), MakeOrder (), ConfirmOrder (), VerifyOrder (), SubmitOrder (), CheckStockAvailability (), CancelOrder () À partir de ces méthodes, pouvez-vous me dire quelle séquence je dois utiliser pour traiter une commande? Pouvez-vous me dire quand je suis autorisé à appeler CancelOrder ()? Dois-je vérifier la disponibilité avant de confirmer la commande? Dois-je vérifier la commande avant de vérifier la disponibilité? Il est peu probable que cette intercface soit cohérente avec celle de la paie.
Darrel Miller

1
@Darrel: Je ne vois pas comment REST aide à résoudre ce problème. Donne-t-il MakeOrderdes URL pour ConfirmOrderet CancelOrder? Le client ne sait-il pas déjà comment appeler le service, mais doit plutôt être basé sur les données?
John Saunders

1
@John Exactement. Le client sait que l'url ConfirmOrder et l'url CancelOrder peuvent lui être fournies, mais il ne sait pas à quoi ressemblent ces URL et ne les suivra que si elles sont fournies. Vous l'appelez piloté par les données, Roy l'appelle Hypermedia comme étant le moteur de l'état de l'application.
Darrel Miller

@Darrel: Je suppose que je n'ai tout simplement jamais vu de service critique pour l'entreprise où je veux déterminer quoi appeler ensuite en fonction de l'URL qui m'a été transmise lors de l'appel précédent.
John Saunders

1
@JohnSaunders: c'est parce qu'un appel REST ne concerne pas les appels de méthode, mais la transition d'état (pensez machine à états). Dans n'importe quel état donné, un serveur RESTful spécifierait des transitions d'état valides et l'utilisateur ou l'agent utilisateur choisit les transitions qu'il souhaite suivre.
Lie Ryan

4

La plupart des réponses "pro" à propos de REST semblent provenir de personnes qui n'ont jamais développé de service Web SOAP ou de client utilisant un environnement qui fournit les outils appropriés pour la tâche. Ils se plaignent de problèmes que je n'ai tout simplement jamais rencontrés, en utilisant Visual Studio .NET et 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 un autre langage avec peu ou pas de support d'outils, ce sont des plaintes valables.

Je dois également admettre que plusieurs des points «pro» semblent être des choses qui pourraient être vraies - mais que je n'ai jamais vu d'exemple illustrant leur valeur. En particulier, j'apprécierais grandement que quelqu'un publie un commentaire contenant un lien vers un bon exemple de service Web REST. Cela doit être celui qui utilise plusieurs niveaux de ressources, éventuellement dans une hiérarchie, et qui utilise correctement les types de médias. Peut-être que si je regarde un bon exemple, je comprendrai, dans ce cas, je reviendrai ici et je l'admettrai.


Le meilleur exemple visible publiquement à ce jour est l'API Sun Cloud. Voici une procédure pas à pas kenai.com/projects/suncloudapis/pages/… Juste pour qualifier mon expérience avec SOAP. J'ai construit et je prends toujours en charge les services Web ASMX à l'aide de la fabrique de logiciels de service Web de Microsoft du groupe Patterns and Practices. J'ai créé des services basés sur WCF en utilisant une version ultérieure de la même fabrique de logiciels. J'ai également utilisé System.ServiceModel.Web de WCF depuis sa première publication avec le SDK Biztalk Services en mai 2007.
Darrel Miller

1
John - un exemple d'API de repos est celui d'Amazon. Ils ont à la fois un @SOAP et une API REST. Cela pourrait être utile pour vous- docs.amazonwebservices.com/AmazonS3/latest/…
RichardOD

3

Pour ajouter une touche un peu prosaïque aux réponses déjà données, la raison pour laquelle nous utilisons les services REST là où je suis est que si vous savez que vous pouvez donner une URL à un partenaire commercial et savoir qu'il recevra, en retour, un bloc de XML bien présenté. peu importe qu'ils travaillent en .Net xx, PHP, Python, Java, Ruby ou Dieu sait ce que cela réduit considérablement les maux de tête.

Cela signifie également que du côté des non-techniciens, nos commerciaux peuvent se vanter de notre API polyvalente auprès des gens sans craindre de ressembler à des muppets complets.

Outre les avantages techniques, tout ce qu'il est facile pour un non-technicien d'expliquer, de démontrer et de se sentir en confiance est une bonne chose. SOAP, bien que tout aussi cool pour les techniciens, est beaucoup moins accessible par les non-techniciens et n'est donc pas aussi facile à «vendre».

J'ai tendance à remarquer que les choses que les non-techniciens peuvent faire tourner la tête ont tendance à rester. Je doute donc que REST en tant que technique soit 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 des personnes qui ne sont pas aussi techniquement intéressées.


3

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 les machines, le simple HTTP est utilisé pour faire 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 des 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 (Créer / Lire / Mettre à jour / Supprimer).

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 beaucoup plus simple.

En dépit d'être simple, REST est complet; il n'y a pratiquement rien que vous puissiez faire dans les services Web qui ne puisse pas être fait avec une architecture RESTful. REST n'est pas un "standard". Il n'y aura jamais de recommandation W3C pour REST, par exemple. Et bien qu'il existe des frameworks de programmation REST, travailler avec REST est si simple que vous pouvez souvent «rouler vous-même» avec des fonctionnalités de bibliothèque standard dans des langages comme Perl, Java ou C #.


« À bien des égards, le World Wide Web lui-même, basé sur HTTP, peut être considéré comme une architecture REST. Les applications RESTful utilisent des 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 (Créer / Lire / Mettre à jour / Supprimer). "Ceci est un autre excellent exemple pratique pour moi à retenir de ce message. Je vous remercie.
Chris22
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.