En quoi consiste exactement la programmation RESTful?
En quoi consiste exactement la programmation RESTful?
Un style architectural appelé REST (Representational State Transfer) préconise que les applications Web utilisent HTTP comme il était initialement envisagé. Les recherches doivent utiliser GET request. Les requêtes PUT, POST et DELETE doivent être utilisées pour mutation, création et suppression, respectivement,.
Les promoteurs de REST ont tendance à préférer les URL, telles que
http://myserver.com/catalog/item/1729
mais l'architecture REST ne nécessite pas ces "jolies URL". Une requête GET avec un paramètre
http://myserver.com/catalog?item=1729
est tout aussi RESTful.
N'oubliez pas que les demandes GET ne doivent jamais être utilisées pour mettre à jour des informations. Par exemple, une demande GET pour ajouter un article à un panier
http://myserver.com/addToCart?cart=314159&item=1729
ne serait pas approprié. Les requêtes GET doivent être idempotent . Autrement dit, émettre une demande deux fois ne devrait pas être différent de l’émettre une fois. C'est ce qui rend les demandes en cache. Une demande "ajouter au panier" n'est pas idempotente - son émission deux fois ajoute deux copies de l'article au panier. Une demande POST est clairement appropriée dans ce contexte. Ainsi, même une application Web RESTful a besoin de sa part de POST requêtes.
Ceci est tiré de l'excellent livre Core JavaServer Faces livre de David M. Geary.
RESTE est le principe architectural sous-jacent du Web. Ce qui est étonnant avec le Web, c’est le fait que les clients (navigateurs) et les serveurs peuvent interagir de manière complexe sans que le client n’en soit informé à l’avance sur le serveur et les ressources qu’il héberge. La principale contrainte est que le serveur et le client doivent tous deux être d’accord sur le média utilisé, qui dans le cas du Web est HTML.
Une API qui adhère aux principes de RESTE ne nécessite pas que le client connaisse la structure de l'API. Le serveur doit plutôt fournir les informations dont le client a besoin pour interagir avec le service. Un formulaire HTML} en est un exemple: le serveur spécifie l'emplacement de la ressource et les champs obligatoires. Le navigateur ne sait pas à l'avance où envoyer les informations et il ne sait pas à l'avance quelles informations envoyer. Les deux types d'informations sont entièrement fournis par le serveur. (Ce principe s'appelle HATEOAS: Hypermédia en tant que moteur de l'état de l'application .)
Alors, comment cela s'applique-t-il à HTTP, et comment peut-il être mis en œuvre dans la pratique? HTTP est orienté autour des verbes et des ressources. Les deux verbes d'usage courant sont GET et POST, ce que tout le monde reconnaîtra, je pense. Cependant, le standard HTTP en définit plusieurs autres tels que PUT et DELETE. Ces verbes sont ensuite appliqués aux ressources, conformément aux instructions fournies par le serveur.
Par exemple, supposons que nous ayons une base de données d’utilisateurs gérée par un service Web. Notre service utilise un hypermédia personnalisé basé sur JSON, pour lequel nous affectons le type MIME application/json + userdb (il peut également y avoir un application/xml + userdb et application/quel que soit + userdb - de nombreux types de média peuvent être supportés). Le client et le serveur ont tous deux été programmés pour comprendre ce format, mais ils ne savent rien l'un de l'autre. Comme Roy Fielding fait remarquer:
Une API REST devrait consacrer la quasi-totalité de ses efforts descriptifs à définir le ou les types de support utilisés pour représenter les ressources et piloter état de l’application, ou dans la définition des noms de relations étendues et/ou balisage hypertexte pour les types de support standard existants.
Une demande pour la ressource de base / peut retourner quelque chose comme ceci:
Demande
GET /
Accept: application/json+userdb
Réponse
200 OK
Content-Type: application/json+userdb
{
"version": "1.0",
"links": [
{
"href": "/user",
"rel": "list",
"method": "GET"
},
{
"href": "/user",
"rel": "create",
"method": "POST"
}
]
}
La description de nos médias nous indique que nous pouvons trouver des informations sur les ressources connexes dans des sections appelées "liens". Cela s'appelle Contrôles Hypermédia. Dans ce cas, nous pouvons dire à partir d'une telle section que nous pouvons trouver une liste d'utilisateurs en faisant une autre demande pour /user:
Demande
GET /user
Accept: application/json+userdb
Réponse
200 OK
Content-Type: application/json+userdb
{
"users": [
{
"id": 1,
"name": "Emil",
"country: "Sweden",
"links": [
{
"href": "/user/1",
"rel": "self",
"method": "GET"
},
{
"href": "/user/1",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/1",
"rel": "delete",
"method": "DELETE"
}
]
},
{
"id": 2,
"name": "Adam",
"country: "Scotland",
"links": [
{
"href": "/user/2",
"rel": "self",
"method": "GET"
},
{
"href": "/user/2",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/2",
"rel": "delete",
"method": "DELETE"
}
]
}
],
"links": [
{
"href": "/user",
"rel": "create",
"method": "POST"
}
]
}
Nous pouvons dire beaucoup de cette réponse. Par exemple, nous savons maintenant que nous pouvons créer un nouvel utilisateur en postant à /user:
Demande
POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Karl",
"country": "Austria"
}
Réponse
201 Created
Content-Type: application/json+userdb
{
"user": {
"id": 3,
"name": "Karl",
"country": "Austria",
"links": [
{
"href": "/user/3",
"rel": "self",
"method": "GET"
},
{
"href": "/user/3",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/3",
"rel": "delete",
"method": "DELETE"
}
]
},
"links": {
"href": "/user",
"rel": "list",
"method": "GET"
}
}
Nous savons également que nous pouvons modifier les données existantes:
Demande
PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Emil",
"country": "Bhutan"
}
Réponse
200 OK
Content-Type: application/json+userdb
{
"user": {
"id": 1,
"name": "Emil",
"country": "Bhutan",
"links": [
{
"href": "/user/1",
"rel": "self",
"method": "GET"
},
{
"href": "/user/1",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/1",
"rel": "delete",
"method": "DELETE"
}
]
},
"links": {
"href": "/user",
"rel": "list",
"method": "GET"
}
}
Notez que nous utilisons différents verbes HTTP (GET, PUT, POST, DELETE, etc.) pour manipuler ces ressources, et que la seule connaissance que nous présumons de la part des clients est notre définition de média.
Lectures complémentaires:
- Les nombreuses réponses bien meilleures sur cette page même.
Comment j'ai expliqué REST à ma femme .- Comment j'ai expliqué REST à ma femme .
- Les pensées de Martin Fowler
- L'API de Paypal a des contrôles hypermédia
(Cette réponse a fait l’objet de nombreuses critiques pour avoir manqué le point. Pour l’essentiel, c’était une critique juste. Ce que j’avais décrit à l’origine était plus conforme à la manière dont REST était habituellement mis en œuvre. Il y a quelques années, lorsque j'ai écrit ceci pour la première fois, plutôt que sa véritable signification, j'ai révisé la réponse pour mieux représenter la véritable signification.)
La programmation RESTful concerne:
- les ressources étant identifiées par un identifiant persistant: les URI sont le choix omniprésent d'identifiant de nos jours
- ressources manipulées à l’aide d’un ensemble commun de verbes: les méthodes HTTP sont le cas habituel - le vénérable
Create,Retrieve,Update,DeletedevientPOST,GET,PUTetDELETE. Mais REST ne se limite pas à HTTP, c'est simplement le transport le plus utilisé à l'heure actuelle. - la représentation réelle extraite pour une ressource dépend de la demande et non de l'identificateur: utilisez les en-têtes Accepter pour déterminer si vous souhaitez utiliser XML, HTTP ou même un objet Java représentant la ressource.
- maintenir l'état dans l'objet et représenter l'état dans la représentation
- représentant les relations entre les ressources dans la représentation de la ressource: les liens entre les objets sont incorporés directement dans la représentation
- les représentations de ressources décrivent comment la représentation peut être utilisée et dans quelles circonstances elle doit être supprimée/extraite de manière cohérente: utilisation des en-têtes HTTP Cache-Control
Le dernier est probablement le plus important en termes de conséquences et d’efficacité globale de REST. Globalement, la plupart des discussions sur RESTful semblent porter sur HTTP et son utilisation à partir d'un navigateur, entre autres. Je comprends que R. Fielding a inventé le terme quand il a décrit l’architecture et les décisions qui mènent à HTTP. Sa thèse porte plus sur l'architecture et la capacité de cache des ressources que sur HTTP.
Si vous êtes vraiment intéressé par ce qu’est une architecture RESTful et pourquoi cela fonctionne, lisez sa thèse quelques fois et lisez le tout pas seulement le chapitre 5! Ensuite, examinez pourquoi le DNS fonctionne-t-il . Lisez à propos de l'organisation hiérarchique du DNS et du fonctionnement des renvois. Ensuite, lisez et considérez le fonctionnement de la mise en cache DNS. Enfin, lisez les spécifications HTTP ( RFC2616 et RFC304 en particulier) et examinez comment et pourquoi la mise en cache fonctionne de la même manière. Finalement, il vous suffira de cliquer. La révélation finale pour moi a été lorsque j'ai vu la similitude entre DNS et HTTP. Après quoi, comprendre pourquoi SOA et les interfaces de transmission de messages sont évolutifs.
Je pense que le truc le plus important pour comprendre l’importance de l’architecture RESTful et Shared Nothing sur le plan de l’architecture et de sa performance est d’éviter de s’attarder sur les détails de la technologie et de la mise en oeuvre. Concentrez-vous sur le propriétaire des ressources, sur le responsable de leur création/maintenance, etc. Ensuite, réfléchissez aux représentations, aux protocoles et aux technologies.
Voici à quoi cela pourrait ressembler.
Créez un utilisateur avec trois propriétés:
POST /user
fname=John&lname=Doe&age=25
Le serveur répond:
200 OK
Location: /user/123
À l'avenir, vous pourrez alors récupérer les informations utilisateur:
GET /user/123
Le serveur répond:
200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>
Pour modifier l'enregistrement (lname et age resteront inchangés):
PATCH /user/123
fname=Johnny
Pour mettre à jour l'enregistrement (et par conséquent lname et age seront NULL):
PUT /user/123
fname=Johnny
Un bon livre sur REST est REST en pratique .
Les lectures obligatoires doivent être Représentation d'état (REST) } et les API REST doivent être pilotées par hypertexte }
Voir l'article de Martin Fowlers le modèle de maturité Richardson (RMM) pour une explication sur ce qu'est un service RESTful.
Pour être RESTful, un service doit remplir les Hypermedia en tant que moteur de l'état de l'application. (HATEOAS) , c'est-à-dire qu'il doit atteindre le niveau 3 de la RMM, lire l'article pour détails ou les diapositives de la conversation qcon .
La contrainte HATEOAS est un acronyme pour Hypermedia en tant que moteur de État d'application. Ce principe est la clé différenciateur entre un REST et la plupart des autres formes de serveur client système.
...
Un client ayant besoin d'une application RESTful connaître uniquement une seule URL fixe à laquelle accéder. il. Toutes les actions futures devraient être découvrable dynamiquement à partir de liens hypermédia inclus dans le représentations des ressources qui sont retournés à partir de cette URL . Les types de supports standardisés sont également devrait être compris par tout client pouvant utiliser une API RESTful. (Un article de Wikipédia, l'encyclopédie libre)
REST Test décisif pour les cadres Web est un test de maturité similaire pour les cadres Web.
_ { En approchant du pur repos: apprendre à aimer HATEOAS } est une bonne collection de liens.
_ { REST par rapport à SOAP pour le cloud public } décrit les niveaux actuels d'utilisation de REST.
REST et la gestion des versions discute de l'extensibilité, de la gestion des versions, de l'évolutivité, etc. par modifiabilité
Qu'est-ce que le repos?
REST est synonyme de Representational State Transfer. (Il est parfois appelé Orthographié "ReST".) Il repose sur un serveur sans état, client-serveur, pouvant être mis en cache protocole de communication - et dans presque tous les cas, HTTP le protocole est utilisé.
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 des machines, un simple HTTP est utilisé pour créer appels entre machines.
À bien des égards, le World Wide Web lui-même, basé sur HTTP, peut être visualisé en tant qu'architecture basée sur REST. Les applications RESTful utilisent des requêtes HTTP 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 CRUD (Créer/Lire/Mettre à jour/Supprimer).
REST est une alternative légère aux mécanismes tels que RPC (Remote Procedure Procedure) et les services Web (SOAP, WSDL, et autres). Plus tard, nous le ferons voyez à quel point REST est beaucoup plus simple.
Bien qu’il soit simple, REST est complet; il y a fondamentalement Rien de ce que vous pouvez faire dans les services Web avec un RESTful architecture. REST n'est pas un "standard". Il n'y aura jamais de W3C recommandation pour REST, par exemple. Et tant qu'il y a REST En utilisant des cadres de programmation, travailler avec REST est si simple que vous pouvez souvent "rouler soi-même" avec des fonctionnalités de bibliothèque standard dans des langues telles que Perl, Java ou C #.
Une des meilleures références que j'ai trouvées lorsque j'essayais de trouver le vrai sens simple du repos.
REST utilise les différentes méthodes HTTP (principalement GET/PUT/DELETE) pour manipuler les données.
Plutôt que d’utiliser une URL spécifique pour supprimer une méthode (par exemple, /user/123/delete), vous devez envoyer une demande DELETE à l’URL /user/[id], pour modifier un utilisateur et récupérer des informations sur un utilisateur auquel vous envoyez une demande GET à /user/[id]
Par exemple, utilisez plutôt un ensemble d’URL qui pourrait ressembler à l’une des suivantes.
GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1
Vous utilisez les "verbes" HTTP et avez ..
GET /user/2
DELETE /user/2
PUT /user
C'est une programmation où l'architecture de votre système correspond au style REST présenté par Roy Fielding dans sa thèse . Comme c'est le style architectural qui décrit le Web (plus ou moins), beaucoup de gens s'y intéressent.
Réponse bonus: Non. Sauf si vous étudiez l'architecture logicielle en tant qu'académique ou que vous concevez des services Web, il n'y a vraiment aucune raison d'avoir entendu le terme.
Je m'excuse si je ne réponds pas directement à la question, mais il est plus facile de comprendre tout cela avec des exemples plus détaillés. Fielding n'est pas facile à comprendre en raison de toute l'abstraction et de la terminologie.
Il y a un assez bon exemple ici:
Expliquer REST et l'hypertexte: Spam-E le robot nettoyeur de spams
Et encore mieux, il y a une explication claire avec des exemples simples ici (le PowerPoint est plus complet, mais vous pouvez en obtenir le maximum dans la version html):
http://www.xfront.com/REST.ppt ou http://www.xfront.com/REST.html
Après avoir lu les exemples, j'ai pu comprendre pourquoi Ken dit que REST est basé sur l'hypertexte. Je ne suis pas sûr qu'il ait raison cependant, car/user/123 est un URI qui pointe vers une ressource, et il m'est difficile de comprendre que ce n'est pas RESTful simplement parce que le client le sait "hors-bande".
Ce document xfront explique la différence entre REST et SOAP, ce qui est également très utile. Lorsque Fielding dit: " C’est RPC. Il crie RPC. ", il est clair que RPC n’est pas RESTful, il est donc utile de voir les raisons exactes. (SOAP est un type de RPC.)
Je dirais que la programmation RESTful consiste à créer des systèmes (API) qui suivent le style architectural REST.
J'ai trouvé ce tutoriel fantastique, court et facile à comprendre sur le sujet REST du Dr M. Elkstein, en citant l'essentiel qui répondrait pour l'essentiel à votre question:
Apprendre le reste: un tutoriel
REST est un style 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 vous connecter entre des machines, un simple HTTP est utilisé pour créer appels entre 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, REPOS utilise HTTP pour les quatre opérations CRUD (Créer/Lire/Mettre à jour/Supprimer).
Je ne pense pas que vous devriez vous sentir stupide de ne pas avoir entendu parler de REST en dehors de Stack Overflow ..., je serais dans la même situation !; réponses à cet autre SO question sur Pourquoi est REST grand maintenant pourrait soulager certains sentiments.
Qu'est-ce que le repos?
REST en termes officiels, REST est un style architectural basé sur certains principes qui s'appuient sur les principes fondamentaux actuels du "Web". Il existe 5 principes fondamentaux du Web qui permettent de créer REST prestations de service.
- Principe 1: Tout est une ressourceIn the REST le style architectural, les données et les fonctionnalités sont considérés comme des ressources et sont accessibles à l'aide d'un identifiant de ressource uniforme (URI), généralement un lien sur le Web.
- Principe 2: Chaque ressource est identifiée par un identifiant unique (URI)
- Principe 3: Utiliser des interfaces simples et uniformes
- Principe 4: La communication se fait par représentation
- Principe 5: Être apatride
Je vois un tas de réponses qui disent que tout ce qui concerne l'utilisateur 123 dans la ressource "/ utilisateur/123" est RESTful.
Roy Fielding, qui a inventé le terme, dit REST Les API doivent être pilotées par l'hypertexte . En particulier, "Une API REST ne doit pas définir de noms de ressources fixes ni de hiérarchies".
Donc, si votre chemin "/ utilisateur/123" est codé en dur sur le client, ce n'est pas vraiment RESTful. Une bonne utilisation de HTTP peut-être, peut-être pas. Mais pas reposant. Cela doit venir de l'hypertexte.
La réponse est très simple, il existe une thèse écrite par Roy Fielding.] 1 Dans cette thèse, il définit les principes REST. Si une application respecte tous ces principes, il s'agit d'une application REST.
Le terme RESTful a été créé parce que ppl a épuisé le mot REST en appelant son application non-REST en tant que REST. Après cela, le terme RESTful était également épuisé. Nous parlons actuellement des API Web et des API Hypermedia , car la plupart des applications REST ne remplissaient pas la partie HATEOAS de la contrainte d'interface uniforme.
Les contraintes REST sont les suivantes:
architecture client-serveur
Donc, cela ne fonctionne pas avec, par exemple, les sockets PUB/SUB, il est basé sur REQ/REP.
communication sans état
Le serveur ne conserve donc pas les états des clients. Cela signifie que vous ne pouvez pas utiliser de stockage de session serveur côté serveur et vous devez authentifier chaque requête. Vos clients peuvent éventuellement envoyer des en-têtes d'authentification de base via une connexion cryptée. (Pour les applications volumineuses, il est difficile de gérer plusieurs sessions.)
utilisation du cache si vous le pouvez
Donc, vous n'avez pas à répondre aux mêmes demandes encore et encore.
interface uniforme en tant que contrat commun entre le client et le serveur
Le contrat entre le client et le serveur n'est pas géré par le serveur. En d'autres termes, le client doit être découplé de la mise en œuvre du service. Vous pouvez atteindre cet état en utilisant des solutions standard, telles que le standard IRI (URI) pour identifier les ressources, le standard HTTP pour échanger des messages, les types MIME standard pour décrire le format de sérialisation du corps, les métadonnées (éventuellement RDF), microformats, etc. etc.) pour décrire la sémantique de différentes parties du corps du message. Pour découpler la structure IRI du client, vous devez envoyer des hyperliens aux clients dans des formats hypermédia tels que (HTML, JSON-LD, HAL, etc.). Ainsi, un client peut utiliser les métadonnées (éventuellement les relations de lien, les vocabulaires RDF) attribuées aux liens hypertexte pour naviguer dans la machine à états de l'application à travers les transitions d'état appropriées afin d'atteindre son objectif actuel.
Par exemple, lorsqu'un client souhaite envoyer une commande à une boutique en ligne, il doit alors vérifier les liens hypertexte dans les réponses envoyées par la boutique en ligne. En vérifiant les liens, il en trouve un décrit avec le http://schema.org/OrderAction . Le client connaît le vocabulaire de schema.org et comprend donc qu'en activant ce lien hypertexte, il enverra la commande. Donc, il active le lien hypertexte et envoie un message
POST https://example.com/api/v1/orderavec le corps approprié. Après cela, le service traite le message et répond avec le résultat ayant l'en-tête d'état HTTP approprié, par exemple201 - createden cas de succès. Pour annoter des messages avec des métadonnées détaillées, la solution standard consiste à utiliser un format RDF, par exemple JSON-LD avec un vocabulaire REST, par exemple Hydra et des vocabulaires spécifiques à un domaine tels que schema.org ou tout autre vocabulaire de données lié et éventuellement un vocabulaire spécifique à une application personnalisée, si nécessaire. Maintenant, ce n’est pas facile, c’est pourquoi la plupart des utilisateurs utilisent HAL et d’autres formats simples qui ne fournissent généralement qu’un vocabulaire REST, mais ne prennent pas en charge les données liées.construire un système en couches pour augmenter l'évolutivité
Le système REST est composé de couches hiérarchiques. Chaque couche contient des composants qui utilisent les services de composants qui se trouvent dans la couche suivante ci-dessous. Vous pouvez donc ajouter de nouveaux calques et composants sans effort.
Par exemple, il existe une couche client contenant les clients et en dessous, une couche service contenant un seul service. Vous pouvez maintenant ajouter un cache côté client entre eux. Après cela, vous pouvez ajouter une autre instance de service et un équilibreur de charge, etc. Le code client et le code de service ne changeront pas.
code à la demande pour étendre les fonctionnalités du client
Cette contrainte est optionnelle. Par exemple, vous pouvez envoyer un analyseur pour un type de média spécifique au client, et ainsi de suite ... Pour ce faire, vous aurez peut-être besoin d'un système de chargeur de plug-in standard dans le client. Sinon, votre client sera couplé à la solution de chargement de plug-in. .
Les contraintes REST résultent en un système hautement évolutif dans lequel les clients sont découplés des implémentations des services. Ainsi, les clients peuvent être réutilisables, en général, tout comme les navigateurs sur le Web. Les clients et les services partagent les mêmes normes et les mêmes vocabulaires, ce qui leur permet de se comprendre malgré le fait que le client ne connaisse pas les détails de la mise en œuvre du service. Cela permet de créer des clients automatisés capables de rechercher et d'utiliser les services REST pour atteindre leurs objectifs. À long terme, ces clients peuvent communiquer entre eux et se faire confiance, tout comme les humains. Si nous ajoutons des modèles d'apprentissage à ces clients, le résultat sera une ou plusieurs IA utilisant le Web des machines au lieu d'un parc de serveurs unique. Donc, à la fin, le rêve de Berners Lee: le web sémantique et l’intelligence artificielle deviendront réalité. Donc, en 2030, nous nous retrouvons avec le Skynet. Jusque là ... ;-)
RESTful (Représentation d’état) La programmation par API permet d’écrire des applications Web dans n’importe quel langage de programmation en respectant 5 logiciels de base style architectural principes:
- Ressource (données, information).
- Identifiant global unique (toutes les ressources sont uniques, identifiées par URI ).
- Interface uniforme - utilise une interface simple et standard (HTTP).
- Représentation - toutes les communications sont effectuées par représentation (par exemple, XML / JSON )
- Stateless (chaque demande se produit en isolation complète, il est plus facile de mettre en cache et d'équilibrer la charge),
En d'autres termes, vous écrivez de simples applications réseau point à point sur HTTP qui utilisent des verbes tels que GET, POST, PUT ou DELETE en implémentant une architecture RESTful qui propose la normalisation de l'interface exposée par chaque «ressource». L'utilisation des fonctionnalités actuelles du Web de manière simple et efficace (architecture hautement réussie, éprouvée et distribuée) n'a rien à voir. C'est une alternative à des mécanismes plus complexes comme SOAP , CORBA et RPC .
La programmation RESTful est conforme à la conception de l'architecture Web et, si elle est correctement implémentée, vous permet de tirer pleinement parti d'une infrastructure Web évolutive.
Si je devais réduire la thèse initiale de REST à 3 phrases courtes, je pense que ce qui suit en résume l'essence:
- Les ressources sont demandées via des URL.
- Les protocoles sont limités à ce que vous pouvez communiquer en utilisant des URL.
- Les métadonnées sont transmises sous forme de paires nom-valeur (paramètres de publication de données et de chaîne de requête).
Après cela, il est facile de tomber dans des débats sur les adaptations, les conventions de codage et les meilleures pratiques.
Il est intéressant de noter que les opérations HTTP POST, GET, DELETE ou PUT ne sont pas mentionnées dans la thèse. Cela doit être l'interprétation ultérieure par quelqu'un d'une "meilleure pratique" pour une "interface uniforme".
En ce qui concerne les services Web, il semble que nous ayons besoin d’un moyen de distinguer les architectures basées sur WSDL et SOAP, ce qui alourdit considérablement l’interface et rend l’interface extrêmement complexe. Ils ont également besoin de cadres supplémentaires et d’outils de développement pour pouvoir être mis en œuvre. Je ne sais pas si REST est le meilleur terme pour distinguer les interfaces de sens commun des interfaces trop techniques telles que WSDL et SOAP. Mais nous avons besoin de quelque chose.
Voici mon aperçu de base de REST. J'ai essayé de démontrer la pensée derrière chacun des composants d'une architecture RESTful afin que la compréhension du concept soit plus intuitive. Espérons que cela aide à démystifier REST pour certaines personnes!
REST (Representational State Transfer) est une architecture de conception qui décrit la manière dont les ressources en réseau (c’est-à-dire les nœuds qui partagent des informations) sont conçues et traitées. En général, une architecture RESTful permet au client (la machine qui demande) et au serveur (la machine qui répond) de demander à lire, à écrire et à mettre à jour des données sans que le client ait besoin de savoir comment le serveur fonctionne et que le serveur peut passer. le retour sans avoir besoin de savoir quoi que ce soit sur le client. OK, cool ... mais comment fait-on cela en pratique?
L’exigence la plus évidente est qu’il soit nécessaire d’avoir un langage universel afin que le serveur puisse dire au client ce qu’il essaie de faire avec la demande et que le serveur réponde.
Mais pour trouver une ressource donnée, puis indiquer au client où réside cette ressource, il doit exister un moyen universel de pointer sur les ressources. C’est là que les identificateurs de ressources universelles (URI) entrent en jeu; ce sont essentiellement des adresses uniques pour trouver les ressources.
Mais l’architecture REST ne s’arrête pas là! Bien que ce qui précède réponde aux besoins de base de ce que nous souhaitons, nous souhaitons également disposer d’une architecture prenant en charge le trafic à volume élevé puisqu’un serveur donné traite généralement les réponses d’un certain nombre de clients. Par conséquent, nous ne voulons pas submerger le serveur en lui demandant de mémoriser les informations relatives aux requêtes précédentes.
Par conséquent, nous imposons la restriction selon laquelle chaque paire requête-réponse entre le client et le serveur est indépendante, ce qui signifie que le serveur n'a pas à se souvenir des requêtes précédentes (états précédents de l'interaction client-serveur) pour répondre à une nouvelle demande. Cela signifie que nous voulons que nos interactions soient apatrides.
Afin de réduire davantage la charge sur notre serveur pour ne pas rétablir les calculs qui ont déjà été effectués récemment pour un client donné, REST permet également la mise en cache. Fondamentalement, la mise en cache consiste à prendre un instantané de la réponse initiale fournie au client. Si le client fait à nouveau la même demande, le serveur peut fournir au client l'instantané plutôt que de rétablir tous les calculs nécessaires à la création de la réponse initiale. Cependant, comme il s'agit d'un instantané, si celui-ci n'a pas expiré, le serveur fixe un délai d'expiration à l'avance et la réponse a été mise à jour depuis le cache initial (la demande donnerait une réponse différente de celle du cache). , le client ne verra pas les mises à jour jusqu'à ce que le cache expire (ou que le cache soit effacé) et que la réponse soit à nouveau rendue à partir de zéro.
La dernière chose que vous constaterez souvent ici à propos des architectures RESTful est qu’elles sont superposées. En fait, nous avons déjà discuté implicitement de cette exigence lors de notre discussion sur l’interaction entre le client et le serveur. En gros, cela signifie que chaque couche de notre système n'interagit qu'avec les couches adjacentes. Ainsi, dans notre discussion, la couche client interagit avec notre couche serveur (et inversement), mais il se peut que d'autres couches serveur aident le serveur principal à traiter une demande avec laquelle le client ne communique pas directement. Au lieu de cela, le serveur transmet la demande si nécessaire.
Maintenant, si tout cela vous semble familier, alors tant mieux. Le protocole HTTP (Hypertext Transfer Protocol), qui définit le protocole de communication via le Web, est une implémentation de la notion abstraite d’architecture RESTful (ou une instance de la classe REST si vous êtes un OOP. fanatique comme moi). Dans cette implémentation de REST, le client et le serveur interagissent via GET, POST, PUT, DELETE, etc., qui font partie du langage universel et les ressources peuvent être pointées à l'aide d'URL.
REST est un modèle architectural et un style d'écriture d'applications distribuées. Ce n'est pas un style de programmation au sens étroit.
Dire que vous utilisez le style REST revient à dire que vous avez construit une maison dans un style particulier: par exemple Tudor ou Victorien. REST en tant que style de logiciel et Tudor ou Victorian en tant que style de maison peuvent être définis par les qualités et les contraintes qui les composent. Par exemple, REST doit avoir une séparation Client Server où les messages sont auto-descriptifs. Les maisons de style Tudor ont des pignons qui se chevauchent et des toits qui sont fortement inclinés avec des pignons faisant face au devant. Vous pouvez lire la thèse de Roy pour en savoir plus sur les contraintes et les qualités qui composent REST.
Contrairement aux styles domestiques, REST a eu du mal à être appliqué de manière systématique et pratique. Cela peut avoir été intentionnel. Laissant sa mise en œuvre réelle au concepteur. Vous êtes donc libre de faire ce que vous voulez, tant que vous respectez les contraintes définies dans la thèse que vous créez les systèmes REST.
Prime:
L'ensemble du Web est basé sur REST (ou REST était basé sur le Web). Par conséquent, en tant que développeur Web, vous voudrez peut-être en prendre conscience, même s'il n'est pas nécessaire d'écrire de bonnes applications Web.
Je pense que le point de repos est la séparation de l'étatfulness en une couche supérieure en utilisant Internet (protocole) comme une couche de transport sans état. La plupart des autres approches mélangent les choses.
C’est la meilleure approche pratique pour gérer les changements fondamentaux de la programmation à l’ère de l’internet. En ce qui concerne les changements fondamentaux, Erik Meijer discute ici du sujet suivant: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . Il résume les cinq effets et présente une solution en la concevant dans un langage de programmation. La solution pourrait également être réalisée au niveau de la plate-forme ou du système, quelle que soit la langue. Le repos pourrait être considéré comme l’une des solutions qui a eu beaucoup de succès dans la pratique actuelle.
Avec un style reposant, vous obtenez et manipulez l'état de l'application sur un Internet peu fiable. Si l'opération en cours échoue pour obtenir l'état correct et actuel, il lui faut le principal à validation nulle pour aider l'application à continuer. S'il ne parvient pas à manipuler l'état, il utilise généralement plusieurs étapes de confirmation pour que les choses restent correctes. En ce sens, reste n’est pas en soi une solution complète, il a besoin des fonctions de la pile d’applications Web pour prendre en charge son fonctionnement.
Compte tenu de ce point de vue, le style de repos n’est pas vraiment lié à Internet ou aux applications Web. C'est une solution fondamentale à de nombreuses situations de programmation. Ce n’est pas simple non plus, c’est une interface très simple à utiliser et une gestion étonnante des autres technologies.
Juste mon 2c.
Edit: Deux autres aspects importants:
Apatridie est trompeur. Il s'agit de l'API reposante, pas de l'application ou du système. Le système doit être avec état. Une conception reposante consiste à concevoir un système avec état basé sur une API sans état. Quelques citations d'un autre QA :
- REST, fonctionne sur des représentations de ressources, chacune identifiée par une URL. Il ne s’agit généralement pas d’objets de données, mais bien de abstractions d’objets complexes.
- REST signifie "representational state transfer" (transfert d'état représentatif), ce qui signifie qu'il est essentiel de communiquer et de modifier l'état de certaines ressources d'un système.
C'est une "discussion" incroyablement longue et pourtant assez déroutante pour le moins.
OMI:
1) Il n’existe pas de programme reposant sans gros joint et beaucoup de bière :)
2) Representational State Transfer (REST) est un style architectural spécifié dans la thèse de Roy Fielding . Il comporte un certain nombre de contraintes. Si votre service/client les respecte, il est alors RESTful. Ça y est.
Vous pouvez résumer (significativement) les contraintes pour:
- communication sans état
- respecter les spécifications HTTP (si HTTP est utilisé)
- communique clairement les formats de contenu transmis
- utiliser hypermédia comme moteur de l'état de l'application
Il y a un autre très bon post qui explique bien les choses.
Beaucoup de réponses copient/collent des informations valides, les mélangeant et ajoutant une certaine confusion. Les gens parlent ici de niveaux, d'URI RESTFul (il n'y en a pas!), Appliquent les méthodes HTTP GET, POST, PUT ... REST n'est pas à ce sujet ou pas seulement à ce sujet.
Par exemple, les liens - il est agréable d’avoir une belle API, mais à la fin, le client/serveur ne se soucie pas vraiment des liens que vous obtenez/envoyez, c’est le contenu qui compte.
En fin de compte tout client RESTful devrait pouvoir utiliser n'importe quel service RESTful tant que le format du contenu est connu.
REST === L'analogie HTTP n'est pas correcte tant que vous n'avez pas insisté sur le fait qu'il "DOIT" être HATEOAS driven.
Roy lui-même l'a effacé ici .
Une API REST doit être entrée sans aucune connaissance préalable au-delà de l'URI initial (signet) et d'un ensemble de types de supports normalisés appropriés pour le public visé (c'est-à-dire qu'il doit être compris par tout client susceptible d'utiliser l'API). . À partir de ce moment, toutes les transitions d’état d’application doivent être dictées par la sélection par le client des choix fournis par le serveur, présents dans les représentations reçues ou impliqués par la manipulation de ces représentations par l’utilisateur. Les transitions peuvent être déterminées (ou limitées par) la connaissance par le client des types de média et des mécanismes de communication des ressources, ces deux éléments pouvant être améliorés à la volée (par exemple, le code à la demande).
[Un échec implique que les informations hors bande génèrent une interaction plutôt qu'un hypertexte.]
Ancienne question, nouvelle façon de répondre. Il y a beaucoup d'idées fausses sur ce concept. J'essaie toujours de me souvenir:
- Les URL structurées et les méthodes/verbes HTTP ne constituent pas la définition de la programmation reposante
- JSON n'est pas une programmation reposante
- La programmation RESTful n'est pas pour les API
Je définis la programmation reposante comme
Une application est reposante si elle fournit des ressources (combinaison des commandes de transitions de données et d’états) dans un type de support compris par le client.
Pour être un programmeur reposant, vous devez essayer de créer des applications permettant aux acteurs de faire des choses. Pas seulement exposer la base de données.
Les contrôles de transition d'état n'ont de sens que si le client et le serveur s'accordent sur une représentation du type de support de la ressource. Sinon, il n'y a aucun moyen de savoir ce qu'est un contrôle et ce qui ne l'est pas et comment exécuter un contrôle. IE Si les navigateurs ne connaissaient pas les balises <form> en html, vous ne pouviez rien soumettre à l'état de transition dans votre navigateur.
Je ne cherche pas à promouvoir moi-même, mais je développe ces idées de manière très approfondie http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .
Un extrait de mon exposé concerne le modèle de maturité richardson souvent évoqué. Je ne crois pas aux niveaux. Vous êtes soit RESTful (niveau 3) ou non, mais ce que j'aime appeler, c’est ce que chaque niveau fait pour vous sur le chemin de RESTful
RESTEest un style architectural basé sur les normes Web et le protocole HTTP (introduit en 2000).
Dans une architecture basée sur REST, tout est une ressource (utilisateurs, ordres, commentaires). L'accès à une ressource est effectué via une interface commune basée sur les méthodes standard HTTP (GET, PUT, PATCH, DELETE, etc.).
Dans une architecture basée sur REST, vous avez un serveur REST qui fournit accès aux ressources. Un client REST peut accéder et modifier le fichier REST Ressources.
Chaque ressource doit prendre en charge les opérations communes HTTP. Les ressources sont identifiées par des ID globaux (généralement des URI).
REST permet aux ressources d'avoir différentes représentations, par exemple, texte, XML, JSON, etc. Le client REST peut demander une représentation spécifique via le protocole HTTP (négociation de contenu).
Méthodes HTTP:
Les méthodes PUT, GET, POST et DELETE sont généralement utilisées dans les architectures basées sur REST. Le tableau suivant donne une explication de ces opérations.
- GET définit un accès en lecture de la ressource sans effets secondaires. La ressource n'est jamais modifiée via une requête GET, par exemple, la requête n'a aucun effet secondaire (idempotent).
- PUT crée une nouvelle ressource. Il doit également être idempotent.
- DELETE supprime les ressources. Les opérations sont idempotentes. Ils peuvent être répétés sans aboutir à des résultats différents.
- Le POST met à jour une ressource existante ou crée une nouvelle ressource.
REST définit 6 contraintes architecturales qui font de tout service Web une API true RESTful.
- Interface uniforme
- Serveur client
- Apatride
- Cacheable
- Système en couches
- Code sur demande (optionnel)
Parler est plus que simplement échanger des informations. Un protocole est en fait conçu de manière à éviter toute conversation. Chaque partie sait quelle est sa tâche car elle est spécifiée dans le protocole. Les protocoles permettent un échange d'informations purement au détriment des modifications éventuelles des actions possibles. Parler, en revanche, permet à une partie de demander quelles autres actions peuvent être entreprises par l’autre partie. Ils peuvent même poser deux fois la même question et obtenir deux réponses différentes, l’état de la partie adverse pouvant avoir changé entre-temps. Parler est une architecture RESTful . La thèse de Fielding spécifie l'architecture à suivre si l'on voulait autoriser les machines à parler entre elles plutôt que simplement communiquer.
RESTE signifie transfert d'état représentationnel.
Il s'appuie sur un protocole de communication sans état, client-serveur et pouvant être mis en cache. Le protocole HTTP est pratiquement utilisé.
REST est souvent utilisé dans les applications mobiles, les sites Web de réseaux sociaux, les outils de mashup et les processus métier automatisés. Le style REST souligne que les interactions entre clients et services sont renforcées par un nombre limité d'opérations (verbes). La flexibilité est fournie en affectant aux ressources (noms) leurs propres indicateurs de ressources universels (URI) uniques.
Il n'y a pas de notion de "programmation RESTful" en soi. Ce serait mieux appelé paradigme RESTful ou encore mieux architecture RESTful. Ce n'est pas un langage de programmation. C'est un paradigme.
En informatique, le transfert d'état représentatif (REST) est un style architectural utilisé pour le développement web.
Le point de repos est que si nous acceptons d'utiliser un langage commun pour les opérations de base (verbes http), l'infrastructure peut être configurée pour les comprendre et les optimiser correctement, par exemple, en utilisant des en-têtes de cache pour mettre en œuvre la mise en cache niveaux.
Avec une opération GET reposante correctement implémentée, peu importe si les informations proviennent de la base de données de votre serveur, du cache de votre serveur, d'un CDN, du cache d'un proxy, du cache de votre navigateur ou du stockage local de votre navigateur. La source à jour la plus rapide et la plus facilement disponible peut être utilisée.
Dire que Rest n'est qu'un changement syntaxique consistant à utiliser des requêtes GET avec un paramètre d'action pour utiliser les verbes http disponibles donne à penser que cela ne présente aucun avantage et est purement esthétique. Le but est d'utiliser un langage qui puisse être compris et optimisé par toutes les parties de la chaîne. Si votre opération GET a une action avec des effets secondaires, vous devez ignorer toute la mise en cache HTTP ou vous obtiendrez des résultats incohérents.
Ceci est très rarement mentionné partout, mais le modèle de maturité de Richardson est l'une des meilleures méthodes pour réellement juger du caractère reposant de son API. Plus à ce sujet ici:
Qu'est-ce que Test d'API ?
Les tests d'API utilisent la programmation pour envoyer des appels à l'API et obtenir le rendement. Il teste le segment à tester comme une boîte noire. L'objectif des tests API est de confirmer l'exécution correcte et le traitement erroné de la pièce précédant sa coordination dans une application.
REST API
REST: Representational State Transfer.
- C’est un ensemble de fonctions sur lesquelles les testeurs effectuent des requêtes et reçoivent des réponses. Dans REST, les interactions de l'API se font via le protocole HTTP.
- REST permet également la communication entre ordinateurs sur un réseau.
- Pour l'envoi et la réception de messages, cela implique l'utilisation de méthodes HTTP et ne nécessite pas de définition de message stricte, contrairement aux services Web.
- Les messages REST acceptent souvent le formulaire au format XML ou JSON (JavaScript Object Notation).
4 Méthodes d'API couramment utilisées: -
- GET: - Il fournit un accès en lecture seule à une ressource.
- POST: - Il est utilisé pour créer ou mettre à jour une nouvelle ressource.
- PUT: - Il est utilisé pour mettre à jour ou remplacer une ressource existante ou pour créer une nouvelle ressource.
- DELETE: - Il est utilisé pour supprimer une ressource.
Étapes pour tester l’API manuellement: -
Pour utiliser l'API manuellement, nous pouvons utiliser des plugins d'API REST basés sur un navigateur.
- Installer le plugin POSTMAN (Chrome)/REST (Firefox)
- Entrez l'URL de l'API
- Sélectionnez la méthode REST
- Sélectionnez le contenu-en-tête
- Entrez Request JSON (POST)
- Cliquez sur envoyer
- Il retournera la réponse en sortie
Je dirais qu'un élément important dans la compréhension de REST réside dans les points d'extrémité ou les mappages, tels que /customers/{id}/balance.
Vous pouvez imaginer un tel point de terminaison comme étant le pipeline de connexion du site Web (front-end) à votre base de données/serveur (back-end). En les utilisant, le serveur frontal peut effectuer des opérations principales définies dans les méthodes correspondantes de tout mappage REST dans votre application.
Ces réponses donnant des exemples de ressources liées sont excellentes mais ne représentent que la moitié du tableau.
Alors, imaginez que vous concevez un site Web. Vous écrivez une histoire,
Je souhaite pouvoir rechercher une adresse par code postal afin de pouvoir choisir une adresse de livraison
Ensuite, vous construisez le site pour amener l'utilisateur dans ce voyage et essayez de lier les pages entre elles dans un flux de travail.
Une conception de site Web qui les a amenés à une recherche d'adresse, puis les a laissés pour copier l'adresse dans le presse-papiers, puis revenir au formulaire d'adresse de livraison ne serait pas très utilisable.
Une API REST utilise des modèles que nous prenons pour acquis sur le Web pour une interaction machine-machine.
La recherche d'une fonction de code postal ne devrait pas être base/addresses/{postcode} et une collection revient, même si chaque adresse est liée à une adresse complète et à des liens d'édition, car c'est une impasse; le consommateur d'API devrait deviner comment utiliser l'adresse.
Au lieu de cela, le motif de la fonctionnalité doit être intégré au flux dans lequel il est utilisé, de sorte que le voyage se termine au début:
1 GET /orders/123/shipping
200 OK { Current shipping details + link to parent + link to address picker }
2 -> GET /orders/123/shipping/addresspicker
200 OK { Link and form for searching for a postcode }
3 -> GET /orders/123/shipping/addresspicker?postcode=tn11tl
200 OK { List of addresses each with link to pick it }
4 -> POST /orders/123/shipping/addresspicker?postcode=tn11tl&pickNo=3
200 OK { Current shipping details + link to parent + link to address picker }
C'est un parcours d'utilisateur et à la fin, vous pouvez voir l'impact du flux sur la commande.
La demande/réponse HTTP ne fait pas strictement partie de REST, mais je ne pense pas que quiconque ait déjà vu une application non HTTP REST.
Maintenant, ces URL peuvent être n’importe quel jeu de caractères, c’est juste des identifiants, je les ai jolies parce qu’elles ont un sens pour les gens. Une machine utiliserait la rel pour déterminer ce qu’elle ferait, sans dépendre d’une lisible href.