Qu'est-ce que la programmation RESTful?

Qu'est-ce que la programmation RESTful?

Un style architectural appelé REST (Representational State Transfer) préconise que les applications Web utilisent HTTP comme il était initialement prévu . Les recherches doivent utiliser des GETrequêtes. PUT, POSTet les DELETErequêtes doivent être utilisées pour la mutation, la création et la suppression respectivement .

Les partisans de REST ont tendance à privilégier 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.

Gardez à l'esprit 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 demandes GET doivent être idempotentes . Autrement dit, émettre une demande deux fois ne devrait pas être différent de l’émettre une fois. C'est ce qui rend les requêtes cachables. Une demande "ajouter au panier" n'est pas idempotente - émettre deux fois ajoute deux exemplaires 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 requêtes POST.

Ceci est tiré de l'excellent livre Core JavaServer faces book de David M. Geary.

REST est le principe architectural sous-jacent du Web. La chose étonnante sur le Web est le fait que les clients (navigateurs) et les serveurs peuvent interagir de manière complexe sans que le client ne sache quoi que ce soit au préalable sur le serveur et les ressources qu'il héberge. La principale contrainte est que le serveur et le client doivent tous deux s'accorder sur le support utilisé, qui dans le cas du Web est HTML .

Une API qui adhère aux principes de REST n'exige pas que le client sache quoi que ce soit sur la structure de l'API. Le serveur doit plutôt fournir toutes 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ù soumettre les informations et il ne sait pas à l'avance quelles informations soumettre. Les deux formes d'informations sont entièrement fournies par le serveur. (Ce principe est appelé HATEOAS : Hypermedia As The Engine Of Application State .)

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 GETet POST, que je pense que tout le monde reconnaîtra. Cependant, la norme HTTP en définit plusieurs autres comme PUTet DELETE. Ces verbes sont ensuite appliqués aux ressources, selon les instructions fournies par le serveur.

Par exemple, imaginons que nous avons 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 attribuons le type MIME application/json+userdb(il peut également y avoir un application/xml+userdbet application/whatever+userdb- de nombreux types de supports peuvent être pris en charge). Le client et le serveur ont tous deux été programmés pour comprendre ce format, mais ils ne se connaissent pas. Comme le souligne Roy Fielding :

Une API REST doit consacrer presque tout son effort descriptif à définir le ou les types de média utilisés pour représenter les ressources et piloter l'état de l'application, ou à définir des noms de relation étendus et / ou un balisage hypertexte pour les types de média standard existants.

Une demande pour la ressource de base / peut renvoyer 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"
        }
    ]
}

Nous savons de la description de nos médias que nous pouvons trouver des informations sur les ressources connexes dans les sections appelées "liens". C'est ce qu'on appelle les contrôles Hypermedia . Dans ce cas, nous pouvons dire à partir d'une telle section que nous pouvons trouver une liste d'utilisateurs en faisant une autre demande de/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 en dire beaucoup de cette réponse. Par exemple, nous savons maintenant que nous pouvons créer un nouvel utilisateur par POSTING /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, DELETEetc.) pour manipuler ces ressources, et que la seule connaissance que nous présumons de la part du client est notre définition de médias.

Lectures complémentaires:

• Les nombreuses réponses bien meilleures sur cette même page.
• Comment j'ai expliqué REST à ma femme .
• Comment j'ai expliqué REST à ma femme .
• Les pensées de Martin Fowler
• L'API de PayPal dispose de contrôles hypermédia

(Cette réponse a fait l'objet de nombreuses critiques pour avoir manqué le point. Pour l'essentiel, cette critique a été juste. Ce que j'ai décrit à l'origine correspondait davantage à la façon dont REST était généralement mis en œuvre il y a quelques années a d'abord écrit ceci, plutôt que sa vraie signification. J'ai révisé la réponse pour mieux représenter la vraie signification.)

La programmation RESTful concerne:

• ressources identifiées par un identifiant persistant: les URI sont le choix omniprésent de l'identifiant de nos jours
• les ressources manipulées en utilisant un ensemble commun de verbes: les méthodes HTTP sont le cas souvent vu - le vénérable Create, Retrieve, Update, Deletedevient POST, GET, PUTet DELETE. Mais REST n'est pas limité à HTTP, c'est juste le transport le plus utilisé actuellement.
• la représentation réelle récupérée pour une ressource dépend de la demande et non de l'identifiant: utilisez les en-têtes Accept pour contrôler si vous voulez XML, HTTP ou même un objet Java représentant la ressource
• maintien de l'état dans l'objet et représentation de l'état dans la représentation
• représenter les relations entre ressources dans la représentation de la ressource: les liens entre objets sont directement intégrés 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 / récupérée 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. Dans l'ensemble, la plupart des discussions RESTful semblent se concentrer sur HTTP et son utilisation à partir d'un navigateur et ainsi de suite. 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 davantage sur l'architecture et la capacité de mise en cache des ressources que sur HTTP.

Si vous êtes vraiment intéressé par ce qu'est une architecture RESTful et pourquoi elle fonctionne, lisez sa thèse plusieurs fois et lisez le tout pas seulement le chapitre 5! Découvrez ensuite pourquoi DNS fonctionne . Apprenez-en plus sur l'organisation hiérarchique du DNS et sur le fonctionnement des références. Ensuite, lisez et réfléchissez au fonctionnement de la mise en cache DNS. Enfin, lisez les spécifications HTTP ( RFC2616 et RFC3040 en particulier) et considérez comment et pourquoi la mise en cache fonctionne comme elle le fait. Finalement, il suffit de cliquer. La dernière révélation pour moi a été quand j'ai vu la similitude entre DNS et HTTP. Après cela, comprendre pourquoi SOA et les interfaces de passage de messages sont évolutives commence à cliquer.

Je pense que l'astuce la plus importante pour comprendre l'importance architecturale et les implications en termes de performances des architectures RESTful et Shared Nothing est d'éviter de rester accroché aux détails de la technologie et de la mise en œuvre. Concentrez-vous sur qui possède les ressources, qui est responsable de leur création / maintenance, etc. Réfléchissez ensuite aux représentations, protocoles et technologies.

Voilà à 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 ensuite 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 ( lnameet agerestera inchangé):

PATCH /user/123
fname=Johnny

Pour mettre à jour l'enregistrement (et par conséquent lnameet agesera NULL):

PUT /user/123
fname=Johnny

Un excellent livre sur REST est REST in Practice .

Les lectures doivent être REST (Representational State Transfer) et les API REST doivent être pilotées par hypertexte

Voir l'article de Martin Fowlers sur le modèle de maturité Richardson (RMM) pour une explication sur ce qu'est un service RESTful.

Pour être RESTful, un service doit remplir l' hypermédia en tant que moteur d'état de l'application. (HATEOAS) , c'est-à-dire qu'il doit atteindre le niveau 3 dans le RMM, lire l'article pour plus de détails ou les diapositives de la conférence qcon .

La contrainte HATEOAS est un acronyme pour Hypermedia en tant que moteur d'état de l'application. Ce principe est le principal différenciateur entre un REST et la plupart des autres formes de système client-serveur.

...

Un client d'une application RESTful n'a besoin que d'une seule URL fixe pour y accéder. Toutes les actions futures devraient être détectables dynamiquement à partir de liens hypermédia inclus dans les représentations des ressources qui sont retournées à partir de cette URL. Les types de supports normalisés devraient également être compris par tout client qui pourrait utiliser une API RESTful. (Un article de Wikipédia, l'encyclopédie libre)

Test décisif REST pour les cadres Web est un test de maturité similaire pour les cadres Web.

Approche du pur repos: apprendre à aimer HATEOAS est une bonne collection de liens.

REST contre SOAP pour le cloud public traite des niveaux actuels d'utilisation de REST.

REST et le contrôle de version discutent de l'extensibilité, du contrôle de version, de l'évolutivité, etc. via la modifiabilité

Qu'est-ce que REST?

REST signifie Representational State Transfer. (Il est parfois orthographié "ReST".) Il s'appuie sur un protocole de communication sans serveur, client-serveur, pouvant être mis en cache - et dans pratiquement tous les cas, le protocole HTTP 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 machines, un simple HTTP est utilisé pour effectuer des 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, 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 (appels de procédure distante) et aux services Web (SOAP, WSDL, et al.). Plus tard, nous verrons combien REST est plus simple.

Bien qu'il soit simple, REST est complet; il n'y a pratiquement rien que vous puissiez faire dans les services Web qui ne peut 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 cadres de programmation REST, travailler avec REST est si simple que vous pouvez souvent "rouler le vôtre" avec des fonctionnalités de bibliothèque standard dans des langages comme Perl, Java ou C #.

L'une des meilleures références que j'ai trouvées lorsque j'essaie de trouver le vrai sens simple du repos.

http://rest.elkstein.org/

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 enverriez une demande DELETE à l' /user/[id]URL, pour modifier un utilisateur, pour récupérer des informations sur un utilisateur auquel vous envoyez une demande GET/user/[id]

Par exemple, à la place, un ensemble d'URL qui pourraient ressembler à certaines 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 la programmation où l'architecture de votre système correspond au style REST présenté par Roy Fielding dans sa thèse . Puisque 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'universitaire ou que vous concevez des services Web, il n'y a vraiment aucune raison d'avoir entendu le terme.

Je dirais que la programmation RESTful consisterait à créer des systèmes (API) qui suivent le style architectural REST.

J'ai trouvé ce tutoriel fantastique, court et facile à comprendre sur REST par le Dr M. Elkstein et citant l'essentiel qui répondrait à votre question pour la plupart:

Learn REST: A Tutorial

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, un simple HTTP est utilisé pour effectuer des 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, REST 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 entendre parler de REST en dehors de Stack Overflow ..., je serais dans la même situation !; les réponses à cette autre question SO sur Pourquoi le REST prend de l'ampleur maintenant pourraient atténuer certains sentiments.

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. Le champ n'est pas facile à comprendre en raison de toute l'abstraction et de la terminologie.

Il y a un assez bon exemple ici:

Explication de REST et de l'hypertexte: Spam-E, le robot de nettoyage du spam

Et encore mieux, il y a une explication claire avec des exemples simples ici (le powerpoint est plus complet, mais vous pouvez en obtenir la plupart dans la version html):

http://www.xfront.com/REST.ppt ou http://www.xfront.com/REST.html

Après avoir lu les exemples, je pouvais voir pourquoi Ken disait que REST est basé sur l'hypertexte. Je ne suis pas sûr qu'il ait raison cependant, parce que / user / 123 est un URI qui pointe vers une ressource, et il n'est pas clair pour moi qu'il n'est pas reposant simplement parce que le client le sait "hors bande".

Ce document xfront explique la différence entre REST et SOAP, et cela 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 de cela. (SOAP est un type de RPC.)

Qu'est-ce que REST?

REST en termes officiels, REST est un style architectural construit sur certains principes en utilisant les principes fondamentaux du «Web». Il existe 5 principes de base du Web qui sont mis à profit pour créer des services REST.

• Principe 1: tout est une ressource Dans le style architectural REST, les données et les fonctionnalités sont considérées comme des ressources et sont accessibles à l'aide d'URI (Uniform Resource Identifiers), généralement des liens 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 mettre sur l'utilisateur 123 dans la ressource "/ user / 123" est RESTful.

Roy Fielding, qui a inventé le terme, dit que les API REST doivent être basées sur l'hypertexte . En particulier, "Une API REST ne doit pas définir de noms ou de hiérarchies de ressources fixes".

Donc, si votre chemin "/ user / 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 y a une thèse écrite par Roy Fielding.] 1 Dans cette thèse, il définit les principes REST. Si une application remplit 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 leur application non-REST comme REST. Après cela, le terme RESTful a également été épuisé. De nos jours, nous parlons d'API Web et d'API Hypermedia , car la plupart des applications dites REST ne remplissaient pas la partie HATEOAS de la contrainte d'interface uniforme.

Les contraintes REST sont les suivantes:

1. architecture client-serveur

   Il ne fonctionne donc pas avec par exemple les sockets PUB / SUB, il est basé sur REQ / REP.

2. communication apatride

   Le serveur ne conserve donc pas les états des clients. Cela signifie que vous ne pouvez pas utiliser un serveur de stockage de session secondaire et que vous devez authentifier chaque demande. Vos clients peuvent éventuellement envoyer des en-têtes d'authentification de base via une connexion cryptée. (Pour les grandes applications, il est difficile de maintenir de nombreuses sessions.)

3. utilisation du cache si vous le pouvez

   Vous n'avez donc pas à répondre aux mêmes demandes encore et encore.

4. interface uniforme comme 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 dissocié de la mise en œuvre du service. Vous pouvez atteindre cet état en utilisant des solutions standard, comme la norme IRI (URI) pour identifier les ressources, la norme HTTP pour échanger des messages, des types MIME standard pour décrire le format de sérialisation du corps, des métadonnées (éventuellement des vocabulaires RDF, des microformats, etc.) pour décrire la sémantique des 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 comme (HTML, JSON-LD, HAL, etc.). Ainsi, un client peut utiliser les métadonnées (éventuellement des relations de liens, des vocabulaires RDF) attribuées aux hyperliens pour naviguer dans la machine d'état 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 hyperliens dans les réponses envoyées par la boutique en ligne. En vérifiant les liens, il en trouve un décrit avec http://schema.org/OrderAction . Le client connaît le vocabulaire schema.org, il comprend donc qu'en activant cet hyperlien il enverra la commande. Il active donc l'hyperlien et envoie un POST https://example.com/api/v1/ordermessage avec 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 exemple 201 - createdpar succès. Pour annoter des messages avec des métadonnées détaillées, la solution standard pour utiliser un format RDF, par exemple JSON-LD avec un vocabulaire REST, par exemple Hydra et des vocabulaires spécifiques au domaine commeschema.org ou tout autrevocabulaire de données liéeset peut-être un vocabulaire spécifique à l'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 pas de support de données liées.

5. 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 des composants qui se trouvent dans la couche suivante ci-dessous. Vous pouvez donc ajouter de nouveaux calques et composants sans effort.

   Par exemple, il y a une couche client qui contient les clients et en dessous il y a une couche service qui contient 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.

6. code à la demande pour étendre les fonctionnalités du client

   Cette contrainte est facultative. Par exemple, vous pouvez envoyer un analyseur pour un type de média spécifique au client, etc. .

Les contraintes REST résultent d'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, tout comme les navigateurs sur le Web. Les clients et les services partagent les mêmes normes et vocabulaires, afin qu'ils puissent se comprendre malgré le fait que le client ne connaît pas les détails de mise en œuvre du service. Cela permet de créer des clients automatisés qui peuvent trouver et utiliser les services REST pour atteindre leurs objectifs. À long terme, ces clients peuvent communiquer entre eux et se faire confiance pour les tâches, 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 de 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 arrêtés par le Skynet. Jusque là ... ;-)

La programmation de l'API RESTful (Representational State Transfer) consiste à écrire des applications Web dans n'importe quel langage de programmation en suivant 5 principes de base du style architectural du logiciel :

1. Ressource (données, informations).
2. Identifiant global unique (toutes les ressources sont uniques identifiées par l' URI ).
3. Interface uniforme - utilisez une simple et standard (HTTP).
4. Représentation - toutes les communications se font par représentation (par exemple XML / JSON )
5. Sans état (chaque requête se déroule dans un isolement complet, 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 standardisation de l'interface que chaque «ressource» expose. Ce n'est rien que d'utiliser les fonctionnalités actuelles du Web de manière simple et efficace (architecture très réussie, éprouvée et distribuée). C'est une alternative aux 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 mise en œuvre, elle vous permet de tirer pleinement parti d'une infrastructure Web évolutive.

Si je devais réduire la dissertation originale sur REST à seulement 3 phrases courtes, je pense que ce qui suit capture son essence:

1. Les ressources sont demandées via des URL.
2. Les protocoles sont limités à ce que vous pouvez communiquer en utilisant des URL.
3. Les métadonnées sont transmises sous forme de paires nom-valeur (données de publication et paramètres 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.

Fait intéressant, il n'y a aucune mention des opérations HTTP POST, GET, DELETE ou PUT dans la dissertation. Cela doit être l'interprétation ultérieure de 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 qui ajoutent une surcharge considérable et sans doute une complexité beaucoup plus inutile à l'interface. Ils nécessitent également des cadres et des outils de développement supplémentaires pour être mis en œuvre. Je ne sais pas si REST est le meilleur terme pour faire la distinction entre les interfaces de bon sens et les interfaces trop conçues comme WSDL et SOAP. Mais nous avons besoin de quelque chose.

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 strict.

Dire que vous utilisez le style REST revient à dire que vous avez construit une maison dans un style particulier: par exemple Tudor ou Victorian. REST en tant que style logiciel et Tudor ou Victorian en tant que style domestique peuvent être définis par les qualités et les contraintes qui les composent. Par exemple, REST doit avoir une séparation client-serveur où les messages se décrivent d'eux-mêmes. Les maisons de style Tudor ont des pignons et des toits qui se chevauchent et sont fortement inclinés avec des pignons orientés vers l'avant. Vous pouvez lire la dissertation de Roy pour en savoir plus sur les contraintes et les qualités qui composent REST.

Contrairement aux styles de maison, REST a eu du mal à être appliqué de manière cohérente et pratique. C'était peut-être 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 énoncées dans la thèse que vous créez des systèmes REST.

Prime:

Le Web entier est basé sur REST (ou REST était basé sur le Web). Par conséquent, en tant que développeur Web, vous voudrez peut-être le savoir, bien qu'il ne soit pas nécessaire d'écrire de bonnes applications Web.

Voici mon aperçu de base de REST. J'ai essayé de démontrer la pensée derrière chacun des composants dans 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 comment 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 demandeuse) et au serveur (la machine répondante) de demander la lecture, l'écriture et la mise à jour des données sans que le client ait à savoir comment fonctionne le serveur et que le serveur puisse passer revenir sans avoir besoin de savoir quoi que ce soit sur le client. D'accord, cool ... mais comment on fait ça en pratique?

• L'exigence la plus évidente est qu'il doit y avoir un langage universel quelconque pour que le serveur puisse dire au client ce qu'il essaie de faire avec la demande et pour que le serveur réponde.

• Mais pour trouver une ressource donnée et dire ensuite au client où se trouve cette ressource, il doit y avoir un moyen universel de pointer les ressources. C'est là qu'interviennent les URI (Universal Resource Identifiers); 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 voulons, nous voulons également avoir une architecture qui prend en charge un trafic à volume élevé, car un serveur donné gère généralement les réponses d'un certain nombre de clients. Ainsi, nous ne voulons pas submerger le serveur en lui faisant se souvenir des informations sur les requêtes précédentes.

• Par conséquent, nous imposons la restriction selon laquelle chaque paire demande-réponse entre le client et le serveur est indépendante, ce qui signifie que le serveur n'a à se rappeler de rien sur les demandes 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.

• Pour alléger davantage la pression exercée sur notre serveur par la répétition de 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 signifie prendre un instantané de la réponse initiale fournie au client. Si le client fait à nouveau la même demande, le serveur peut lui fournir l'instantané plutôt que de refaire tous les calculs nécessaires pour créer la réponse initiale. Cependant, puisqu'il s'agit d'un instantané, si l'instantané n'a pas expiré - le serveur définit une heure d'expiration à l'avance - et la réponse a été mise à jour depuis le cache initial (c'est-à-dire que la demande donnerait une réponse différente de la réponse mise en cache) , le client ne verra pas les mises à jour tant que le cache n'aura pas expiré (ou que le cache ne sera pas vidé) et que la réponse sera à nouveau rendue à partir de zéro.

• La dernière chose que vous allez souvent ici à propos des architectures RESTful est qu'elles sont en couches. En fait, nous avons déjà implicitement discuté de cette exigence dans notre discussion sur l'interaction entre le client et le serveur. Fondamentalement, cela signifie que chaque couche de notre système interagit uniquement avec les couches adjacentes. Donc, dans notre discussion, la couche client interagit avec notre couche serveur (et vice versa), mais il peut y avoir d'autres couches serveur qui aident le serveur principal à traiter une demande avec laquelle le client ne communique pas directement. Au contraire, le serveur transmet la demande si nécessaire.

Maintenant, si tout cela vous semble familier, c'est parfait. Le protocole de transfert hypertexte (HTTP), qui définit le protocole de communication via le World Wide Web, est une implémentation de la notion abstraite d'architecture RESTful (ou une instance de la classe REST si vous êtes un fanatique de POO 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 vers l'utilisation d'URL.

Je pense que le point reposant est la séparation de l'état dans une couche supérieure tout en utilisant Internet (protocole) comme 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 d'Internet. Concernant les changements fondamentaux, Erik Meijer a une discussion ici: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . Il la résume comme les cinq effets et présente une solution en concevant la solution 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 reposant pourrait être considéré comme l'une des solutions qui a connu un grand succès dans la pratique actuelle.

Avec un style reposant, vous obtenez et manipulez l'état de l'application sur un Internet peu fiable. S'il échoue l'opération en cours pour obtenir l'état correct et actuel, il a besoin du principal de validation zéro pour aider l'application à continuer. S'il ne parvient pas à manipuler l'état, il utilise généralement plusieurs étapes de confirmation pour garder les choses correctes. En ce sens, le repos n'est pas lui-même une solution complète, il a besoin des fonctions dans une autre partie 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 à une application Web. C'est une solution fondamentale à de nombreuses situations de programmation. Ce n'est pas simple non plus, cela rend simplement l'interface vraiment simple et fait face à d'autres technologies de façon étonnante.

Juste mon 2c.

Edit: Deux aspects plus importants:

• L'apatridie est trompeuse. Il s'agit de l'API reposante, pas de l'application ou du système. Le système doit être dynamique. La 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. Ce ne sont généralement pas des objets de données, mais des abstractions d'objets complexes .
  • REST signifie "transfert d'état représentatif", ce qui signifie qu'il s'agit de communiquer et de modifier l'état d'une ressource dans un système.

• Idempotence : une partie souvent négligée de REST est l'idempotence de la plupart des verbes. Cela conduit à des systèmes robustes et à moins d'interdépendance des interprétations exactes de la sémantique .

C'est une "discussion" incroyablement longue et pourtant assez déroutante pour dire le moins.

OMI:

1) La programmation reposante n'existe pas sans un gros joint et beaucoup de bière :)

2) Le transfert d'état représentatif (REST) ​​est un style architectural spécifié dans la thèse de Roy Fielding . Il a un certain nombre de contraintes. Si votre service / client respecte ceux-ci, il est RESTful. Ça y est.

Vous pouvez résumer (de manière significative) les contraintes pour:

• communication apatride
• respecter les spécifications HTTP (si HTTP est utilisé)
• communique clairement les formats de contenu transmis
• utiliser l'hypermédia comme moteur de l'état de l'application

Il y a un autre très bon article qui explique bien les choses.

Beaucoup de réponses copient / collent des informations valides en les mélangeant et en ajoutant une certaine confusion. Les gens parlent ici des niveaux, des URI RESTFul (il n'y en a pas!), Appliquent les méthodes HTTP GET, POST, PUT ... REST ne concerne pas cela ou pas seulement.

Par exemple, les liens - il est agréable d'avoir une API de belle apparence 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 de contenu est connu.

Vieille question, nouvelle façon de répondre. Il y a beaucoup d'idées fausses sur ce concept. J'essaie toujours de me souvenir:

1. Les URL structurées et les méthodes / verbes Http ne sont pas la définition d'une programmation reposante.
2. JSON n'est pas une programmation reposante
3. 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 (c'est-à-dire la combinaison de données et de contrôles de transitions d'état) dans un type de support que le client comprend

Pour être un programmeur reposant, vous devez essayer de créer des applications qui permettent aux acteurs de faire des choses. Non 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 conviennent d'une représentation de type média 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 <form>balises en html, il n'y aurait rien à soumettre à l'état de transition dans votre navigateur.

Je ne cherche pas à me promouvoir, mais je développe ces idées en profondeur dans mon exposé 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 mentionné, je ne crois pas aux niveaux, soit vous êtes RESTful (niveau 3) ou vous ne l'êtes pas, mais ce que j'aime appeler à ce sujet est ce que chaque niveau fait pour vous sur votre chemin vers RESTful

REST définit 6 contraintes architecturales qui font de n'importe quel service Web - une véritable API RESTful .

1. Interface uniforme
2. Serveur client
3. Apatride
4. Cacheable
5. Système en couches
6. Code sur demande (facultatif)

https://restfulapi.net/rest-architectural-constraints/

REST === L'analogie HTTP n'est pas correcte tant que vous ne insistez pas sur le fait qu'elle "DOIT" être pilotée par HATEOAS .

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 un ensemble de types de médias normalisés qui sont appropriés pour le public cible (c'est-à-dire, censés être compris par tout client qui pourrait utiliser l'API). À partir de ce moment, toutes les transitions d'état d'application doivent être déterminées par la sélection par le client des choix fournis par le serveur qui sont présents dans les représentations reçues ou impliqués par la manipulation par l'utilisateur de ces représentations. Les transitions peuvent être déterminées (ou limitées par) la connaissance du client des types de médias et des mécanismes de communication des ressources, qui peuvent tous deux être améliorés à la volée (par exemple, le code à la demande).

[L'échec ici implique que les informations hors bande conduisent à l'interaction plutôt qu'à l'hypertexte.]

REST est un style architectural basé sur les standards du Web et le protocole HTTP (introduit en 2000).

Dans une architecture basée sur REST, tout est une ressource (utilisateurs, commandes, commentaires). Une ressource est accessible 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 disposez d'un serveur REST qui donne accès aux ressources. Un client REST peut accéder aux ressources REST et les modifier.

Chaque ressource doit prendre en charge les opérations courantes HTTP. Les ressources sont identifiées par des ID globaux (qui sont généralement des URI).

REST permet que les ressources aient 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 conduire à des résultats différents.
• POST met à jour une ressource existante ou crée une nouvelle ressource.

REST signifie transfert d'état représentatif .

Il repose sur un protocole de communication sans serveur, client-serveur, pouvant être mis en cache - et dans pratiquement tous les cas, le protocole HTTP est utilisé.

REST est souvent utilisé dans les applications mobiles, les sites Web de réseautage social, les outils de mashup et les processus métier automatisés. Le style REST souligne que les interactions entre les clients et les services sont améliorées en ayant un nombre limité d'opérations (verbes). La flexibilité est fournie en attribuant aux ressources (noms) leurs propres indicateurs de ressources universelles (URI) uniques.

Introduction sur le repos

Parler, c'est plus que simplement échanger des informations . Un protocole est en fait conçu pour qu'aucune conversation n'ait lieu. Chaque partie sait quel est son travail particulier car il est spécifié dans le protocole. Les protocoles permettent un échange d'informations pur au détriment de toute modification des actions possibles. Parler, d'autre part, permet à une partie de demander quelles autres mesures peuvent être prises de l'autre partie. Ils peuvent même poser deux fois la même question et obtenir deux réponses différentes, car l'État de l'autre partie peut avoir changé entre-temps. Parler est une architecture RESTful . La thèse de Fielding spécifie l'architecture que l'on devrait suivre si l'on voulait permettre aux machines de se parler plutôt que simplementcommuniquer .

Il n'y a pas de notion de "programmation RESTful" en soi. Ce serait mieux appelé paradigme RESTful ou encore meilleure architecture RESTful. Ce n'est pas un langage de programmation. C'est un paradigme.

De Wikipédia :

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 (les verbes http), l'infrastructure peut être configurée pour les comprendre et les optimiser correctement, par exemple, en utilisant des en-têtes de mise en cache pour implémenter la mise en cache du tout 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 mémoire 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 de l'utilisation de requêtes GET avec un paramètre d'action à l'utilisation des verbes http disponibles donne l'impression qu'il n'a aucun avantage et est purement cosmétique. Il s'agit d'utiliser un langage compréhensible et optimisable par chaque maillon 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 vous retrouverez avec des résultats incohérents.

Qu'est-ce que l' API Testing ?

Les tests d'API utilisent la programmation pour envoyer des appels à l'API et obtenir le rendement. Ce test considère le segment testé comme une boîte noire. Les tests API ont pour objectif de confirmer la bonne exécution et le traitement maladroit de la partie précédant sa coordination dans une application.

API REST

REST: transfert d'état représentatif.

• Il s'agit d'un ensemble de fonctions sur lesquelles les testeurs effectuent des requêtes et reçoivent des réponses. Dans l'API REST, les interactions se font via le protocole HTTP.
• REST permet également la communication entre ordinateurs entre eux via 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 sous forme de XML ou de notation d'objet JavaScript (JSON).

4 méthodes API couramment utilisées: -

1. GET: - Il fournit un accès en lecture seule à une ressource.
2. POST: - Il est utilisé pour créer ou mettre à jour une nouvelle ressource.
3. PUT: - Il est utilisé pour mettre à jour ou remplacer une ressource existante ou créer une nouvelle ressource.
4. SUPPRIMER: - 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.

1. Installer le plug-in POSTMAN (Chrome) / REST (Firefox)
2. Entrez l'URL de l'API
3. Sélectionnez la méthode REST
4. Sélectionner un en-tête de contenu
5. Entrez la requête JSON (POST)
6. Cliquez sur envoyer
7. Il retournera la réponse de sortie

Étapes pour automatiser l'API REST

Cela est beaucoup moins mentionné partout, mais le modèle de maturité de Richardson est l'une des meilleures méthodes pour juger de la façon dont Restful est son API. En savoir plus ici:

Modèle de maturité de Richardson

Je dirais qu'un élément important dans la compréhension de REST réside dans les points de terminaison 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 (frontal) à votre base de données / serveur (principal). En les utilisant, le frontal peut effectuer des opérations principales définies dans les méthodes correspondantes de tout mappage REST dans votre application.