Qu'est-ce que la programmation RESTful ?

Qu'est-ce que la programmation RESTful ?

MD XF
Question modifiée 16 mars 2017 в 7:47
Programmation
definition rest http
22 mars 2009 в 2:45
17 vues

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 se mettre d'accord sur le média utilisé, qui dans le cas du web est le HTML.

Une API qui adhère aux principes de REST n'exige pas du client qu'il sache quoi que ce soit sur la structure de l'API. Au contraire, le serveur doit 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 l'information, et il ne sait pas à l'avance quelle information soumettre. Les deux formes d'information 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 le mettre en œuvre dans la pratique ? HTTP est orienté autour de verbes et de 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 comme 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 peut aussi y avoir un application/xml+userdb et application/whatever+userdb - de nombreux types de médias 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 le souligne [Roy Fielding][1] :

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

Une requête pour la ressource de base / pourrait retourner quelque chose comme ceci :

Requête

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 les 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 requête pour /user :

Requête

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 apprendre beaucoup de choses à partir de cette réponse. Par exemple, nous savons maintenant que nous pouvons créer un nouvel utilisateur en faisant un POST sur /user :

Requête

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 :

Requête

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 différents verbes HTTP (GET, PUT, POST, DELETE etc.) pour manipuler ces ressources, et que la seule connaissance que nous supposons de la part du client est notre définition du média.

Pour en savoir plus :

(Cette réponse a fait l'objet d'un grand nombre de 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).

[1] : http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Jeremy Moritz
Réponse modifiée 10 avril 2019 в 3:31
Commentaires (39)

REST consiste à utiliser 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 (disons, /user/123/delete), vous enverriez une requête DELETE à l'URL /user/[id], pour modifier un utilisateur, pour récupérer des informations sur un utilisateur vous envoyez une requête GET à /user/[id].

Par exemple, à la place d'un ensemble d'URLs qui pourraient ressembler à ce qui suit .

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
Commentaires (5)

Il s'agit de la programmation où l'architecture de votre système correspond au [style REST][2] défini par Roy Fielding dans [sa thèse][1]. Comme il s'agit du style architectural qui décrit le Web (plus ou moins), beaucoup de gens s'y intéressent.

[1] : http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm [2] : http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Réponse bonus : Non. À moins que vous n'étudiiez l'architecture logicielle en tant qu'universitaire ou que vous ne conceviez des services Web, il n'y a vraiment aucune raison d'avoir entendu ce terme.

Hank Gay
Réponse modifiée 22 mars 2009 в 3:56
Commentaires (4)