Qu'est-ce que la programmation RESTful ?

Question

Qu'est-ce que la programmation RESTful ?

Answer 1

REST est le principe architectural sous-jacent du web. Ce qui est étonnant avec le web, c'est que les clients (navigateurs) et les serveurs peuvent interagir de manière complexe sans que le client ne sache rien au préalable du serveur et des ressources qu'il héberge. La principale contrainte est que le serveur et le client doivent tous deux être d'accord sur les éléments suivants médias utilisé, qui dans le cas du web est HTML .

Une API qui adhère aux principes de REST ne nécessite pas que le client connaisse 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 site 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 l'information, et il ne sait pas à l'avance quelle information soumettre. Ces deux formes d'information sont entièrement fournies par le serveur. (Ce principe est appelé HATEOAS : L'hypermédia comme moteur de l'état des applications .)

Alors, comment cela s'applique-t-il à HTTP et comment la mettre en œuvre dans la pratique ? HTTP est orienté autour des verbes et des ressources. Les deux verbes les plus utilisés sont GET et POST que tout le monde reconnaîtra, je pense. Cependant, la norme HTTP en définit plusieurs autres, telles que PUT et 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 qui est gérée par un service web. Notre service utilise un hypermédia personnalisé basé sur JSON, pour lequel nous attribuons le mimetype application/json+userdb (Il pourrait également y avoir un application/xml+userdb et 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 savent rien l'un de l'autre. Comme Roy Fielding fait remarquer :

Une API REST doit consacrer la quasi-totalité de son effort de description à définir le(s) type(s) de média utilisé(s) pour représenter les ressources et piloter le l'état de l'application, ou à la définition de noms de relations étendues et/ou de balisage hypertexte pour les types de médias standard existants.

Une demande de la ressource de base / pourrait retourner quelque chose comme ça :

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, grâce à la description de notre média, que nous pouvons trouver des informations sur des ressources connexes à partir de sections appelées "liens". C'est ce qu'on 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 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"
        }
    ]
}

Cette réponse nous apprend beaucoup de choses. Par exemple, nous savons maintenant que nous pouvons créer un nouvel utilisateur en POST pour /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"
    }
}

Remarquez que nous utilisons des verbes HTTP différents ( GET , PUT , POST , DELETE etc.) pour manipuler ces ressources, et que la seule connaissance que nous présumons de la part du client est notre définition du média.

Pour en savoir plus :

• 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 réflexions de Martin Fowler de Martin Fowler
• L'API de PayPal comporte des contrôles hypermédia

(Cette réponse a fait l'objet de nombreuses critiques parce qu'elle n'était pas pertinente. Dans la plupart des cas, cette critique est juste. Ce que j'ai décrit à l'origine correspondait davantage à la manière dont REST était généralement mis en œuvre il y a quelques années, lorsque j'ai écrit ce texte pour la première fois, plutôt qu'à sa véritable signification. J'ai révisé la réponse pour mieux représenter la signification réelle).

Answer 2

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.
• les ressources étant manipulées à l'aide d'un ensemble commun de verbes : Les méthodes HTTP sont le cas le plus courant - la vénérable Create , Retrieve , Update , Delete devient POST , GET , PUT et DELETE . Mais REST n'est pas limité à HTTP, c'est simplement 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 que la ressource soit représentée par XML, HTTP ou même un objet Java.
• maintenir l'état dans l'objet et représenter l'état dans la représentation
• représenter les relations entre les ressources dans la représentation de la ressource : les liens entre les objets sont intégrés directement dans la représentation
• les représentations des ressources décrivent comment la représentation peut être utilisée et dans quelles circonstances elle doit être éliminée/réinitialisée de manière cohérente : utilisation des en-têtes HTTP Cache-Control

Le dernier point est probablement le plus important en termes de conséquences et d'efficacité globale de REST. Dans l'ensemble, la plupart des discussions sur REST semblent être centrées sur HTTP et son utilisation à partir d'un navigateur et autres. Je crois savoir que R. Fielding a inventé le terme lorsqu'il a décrit l'architecture et les décisions qui ont conduit à 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 lire le tout cela pas seulement le chapitre 5 ! Regardez ensuite dans pourquoi le DNS fonctionne . Découvrez l'organisation hiérarchique du DNS et le fonctionnement des renvois. Ensuite, lisez et étudiez le fonctionnement de la mise en cache du DNS. Enfin, lisez les spécifications HTTP ( RFC2616 et RFC3040 en particulier) et examiner comment et pourquoi la mise en cache fonctionne de cette manière. Vous finirez par comprendre. La révélation finale pour moi a été lorsque j'ai vu la similitude entre DNS et HTTP. Après cela, comprendre pourquoi la SOA et les interfaces de passage de messages sont évolutives commence à faire tilt.

Je pense que l'astuce la plus importante pour comprendre l'importance architecturale et les implications en termes de performances d'une architecture RESTful et Rien de partagé est d'éviter de s'attacher aux détails de la technologie et de la mise en œuvre. Concentrez-vous sur la question de savoir à qui appartiennent les ressources, qui est responsable de leur création/maintenance, etc. Réfléchissez ensuite aux représentations, aux protocoles et aux technologies.

Answer 3

Voilà à quoi ça 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 sur l'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 restera inchangé) :

PATCH /user/123
fname=Johnny

Pour mettre à jour l'enregistrement (et par conséquent lname et age sera NULL) :

PUT /user/123
fname=Johnny

Answer 4

Un excellent livre sur REST est REST en pratique .

Les lectures incontournables sont Transfert d'état représentationnel (REST) et Les API REST doivent être axées sur l'hypertexte.

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

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

La contrainte HATEOAS est un acronyme pour Hypermedia as the Engine of l'état des applications. Ce principe est le différentiateur clé entre un REST et la plupart des autres formes de systèmes client-serveur serveur.

...

Le client d'une application RESTful n'a besoin connaître une seule URL fixe pour y accéder l'application. Toutes les actions futures doivent être découvrir dynamiquement à partir de liens hypermédias inclus dans les représentations des ressources qui sont renvoyées par cette URL. Les types de médias normalisés doivent également également être compris par tout client client qui pourrait utiliser une API RESTful. (Extrait de Wikipédia, l'encyclopédie libre)

Test Litmus REST pour les cadres Web est un test de maturité similaire pour les frameworks web.

Approche du REST pur : Apprendre à aimer les HATEOAS est une bonne collection de liens.

REST versus SOAP pour le cloud public discute des niveaux actuels d'utilisation de REST.

REST et versioning traite de l'extensibilité, du versionnage, de l'évolutivité, etc. à travers la modifiabilité

Answer 5

Qu'est-ce que REST ?

REST est l'abréviation de Representational State Transfer. (Il est parfois orthographié "ReST"). Il repose sur un système de communication sans état, client-serveur, avec possibilité de mise en cache. sans état, 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 les machines, le simple HTTP est utilisé pour faire des appels entre les machines. appels entre les machines.

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

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

Bien qu'il soit simple, REST est très complet. il n'y a rien que vous puissiez faire dans les services Web qui ne puisse être fait avec une une architecture RESTful. REST n'est pas une "norme". Il n'y aura jamais de recommandation du W3C pour REST, par exemple. Et même s'il existe des cadres de programmation REST il existe des cadres de programmation REST, travailler avec REST est si simple que vous pouvez que vous pouvez souvent vous débrouiller tout seul avec les fonctions de la bibliothèque standard dans des langages comme Perl, Java ou C#. Perl, Java ou C#.

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

http://rest.elkstein.org/