Question Quelle est exactement la programmation RESTful?


Quelle est exactement la programmation RESTful?


3628
2018-03-22 14:45


origine


Réponses:


Un style architectural appelé REST (transfert d'état représentationnel) préconise que les applications Web utilisent HTTP comme il était initialement envisagé. Les recherches devraient utiliser GET demandes PUT, POST, et DELETE demande devrait être utilisé pour mutation, création et suppression respectivement.

Les promoteurs 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 requêtes GET ne doivent jamais être utilisées pour la mise à jour des informations. Par exemple, une requête GET pour ajouter un élément à un panier

http://myserver.com/addToCart?cart=314159&item=1729

ne serait pas approprié. Les demandes 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 cachables. Une requête "ajouter au panier" n'est pas idempotente. L'émission deux fois ajoute deux copies de l'article au panier. Une demande POST est clairement appropriée dans ce contexte. Ainsi, même un Application web RESTful a besoin de sa part de requêtes POST.

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


540
2018-04-15 11:26



DU REPOS 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 quoi que ce soit au préalable sur le serveur et les ressources qu'il héberge. La contrainte clé est que le serveur et le client doivent se mettre d'accord médias utilisé, qui dans le cas de la toile est HTML.

Une API qui adhère aux principes de DU REPOS 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 Formulaire HTML Voici un exemple: Le serveur spécifie l'emplacement de la ressource et les champs requis. 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 comme moteur de l'état de l'application.)

Alors, comment cela s'applique à HTTP, et comment peut-il être mis en œuvre dans la pratique? HTTP est orienté autour des verbes et des ressources. Les deux verbes en usage courant sont GET et POST, que je pense que tout le monde reconnaîtra. Cependant, le standard HTTP définit plusieurs autres tels que PUT et DELETE. Ces verbes sont ensuite appliqués aux ressources, selon les instructions fournies par le serveur.

Par exemple, Imaginons que nous ayons une base de données utilisateur 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 pourrait aussi y avoir un application / xml + userdb et application / quelquechose + 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 presque tout son effort descriptif   définir le (s) type (s) de média utilisé (s) pour représenter les ressources et la conduite   l'état de l'application ou pour définir des noms de relations étendues et / ou   balisage hypertexte activé pour les types de média standard existants.

Une requête pour la ressource de base / pourrait 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 à partir de sections appelées «liens». C'est appelé 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 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 aussi que nous pouvons changer 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 supposons sur la partie client est notre définition de média.

En lire plus:

(Cette réponse a fait l'objet de nombreuses critiques pour avoir manqué le point.) La plupart du temps, c'était une critique juste. J'ai d'abord écrit ceci, plutôt que son vrai sens.J'ai révisé la réponse pour mieux représenter le sens réel.)


2788
2018-03-22 19:37



La programmation RESTful concerne:

  • les ressources étant identifiées par un identifiant persistant: les URI sont le choix omniprésent de l'identifiant ces jours-ci
  • les ressources sont manipulées en utilisant un ensemble commun de verbes: les méthodes HTTP sont le cas le plus souvent vu - le vénérable Create, Retrieve, Update, Delete devient POST, GET, PUT, et DELETE. Mais REST n'est pas limité à HTTP, c'est juste le transport le plus couramment utilisé en ce moment.
  • la représentation réelle récupérée pour une ressource dépend de la requête et non de l'identificateur: use Accepte les en-têtes pour contrôler si vous voulez 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é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 rejeté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 ce n'est pas le cas. 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 le protocole 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 lire le la totalité pas seulement le chapitre 5! Prochain regard dans pourquoi DNS fonctionne. Lisez à propos de l'organisation hiérarchique du DNS et du fonctionnement des références. Ensuite, lisez et considérez comment la mise en cache DNS fonctionne. 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 va juste cliquer. La révélation finale pour moi était quand j'ai vu la similitude entre DNS et HTTP. Après cela, comprendre pourquoi SOA et les interfaces de passage de message sont évolutives commence à cliquer.

Je pense que l'astuce la plus importante pour comprendre l'importance architecturale et les implications de performance d'un RESTful et Rien partagé architectures est d'éviter d'être accroché sur la technologie et les détails de mise en œuvre. Concentrez-vous sur qui possède les ressources, qui est responsable de les créer / les maintenir, etc. Ensuite, pensez aux représentations, aux protocoles et aux technologies.


500
2017-07-04 05:47



C'est ce que ç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 ensuite récupérer les informations de 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 le dossier (et par conséquent lname et age sera nul):

PUT /user/123
fname=Johnny

392
2017-11-18 20:46



Un bon livre sur REST est REST dans la pratique.

Les lectures doivent être Transfert d'état représentationnel (REST) et Les API REST doivent être basées sur un lien hypertexte 

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

Richardson Maturity Model

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

La contrainte HATEOAS est un acronyme   pour Hypermedia comme le moteur de   État de l'application Ce principe est   le différentiateur clé entre un REST   et la plupart des autres formes de serveur client   système.

...

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

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

Approche de REST pur: Apprendre à aimer 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é, de la gestion des versions, de l'évolutivité, etc.  par Modifiability


170
2018-03-22 15:20



Qu'est-ce que REST?

REST signifie Representational State Transfer. (C'est parfois   épelé "ReST".) Il repose sur un apatride, client-serveur, cacheable   protocole de communication - et dans presque tous les cas, le HTTP   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 les machines, HTTP simple est utilisé pour faire   appels entre machines.

À bien des égards, le World Wide Web lui-même, basé sur HTTP, peut être consulté   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, faire des requêtes),   et supprimer des données. Ainsi, REST utilise HTTP pour les quatre CRUD   (Créer / Lire / Mettre à jour / Supprimer) les opérations.

REST est une alternative légère aux mécanismes tels que RPC (Remote   Appels de procédure) et services Web (SOAP, WSDL, et al.). Plus tard, nous allons   voir à quel point REST est plus simple.

En dépit d'être simple, REST est complet; il y a essentiellement   rien que vous pouvez faire dans les services Web qui ne peut pas être fait avec un RESTful   architecture. REST n'est pas un "standard". Il n'y aura jamais de W3C   recommendataion pour REST, par exemple. Et tandis qu'il y a REST   cadres de programmation, travailler avec REST est si simple que vous pouvez   souvent "rouler le vôtre" avec des fonctionnalités de bibliothèque standard dans des langues comme   Perl, Java ou C #.

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

http://rest.elkstein.org/


128
2018-03-22 14:53



REST utilise les diverses 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 requête DELETE au /user/[id] URL, pour modifier un utilisateur, pour récupérer des informations sur un utilisateur à qui vous envoyez une requête GET /user/[id]

Par exemple, à la place, un ensemble d'URL qui pourrait ressembler à certains des éléments suivants:

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

85
2017-07-12 16:33



C'est la programmation où l'architecture de votre système correspond à la Style REST aménagé 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 comme un service académique ou la conception de services Web, il n'y a vraiment aucune raison d'avoir entendu le terme.


63
2018-03-23 17:11



Je dirais que la programmation RESTful serait sur la création de systèmes (API) qui suivent le style architectural REST.

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

Apprendre REST: un tutoriel

REST est un style d'architecture pour concevoir des 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, HTTP simple est utilisé pour faire   appels entre machines.

  • À bien des égards, le World Wide Web lui-même, basé sur HTTP, peut être vu comme une architecture basée sur REST.

Les applications RESTful utilisent des requêtes HTTP pour publier des données (créer et / ou   mise à 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! réponses à cette autre question SO sur Pourquoi REST devient grand maintenant pourrait pourrait soulager certains sentiments.


43
2017-07-25 09:05



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 la terminologie.

Il y a un assez bon exemple ici:

Expliquer REST et hypertexte: Spam-E le robot de nettoyage de spam

Et encore mieux, il y a une explication claire avec des exemples simples ici (le powerpoint est plus complet, mais vous pouvez l'obtenir 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 voir pourquoi Ken dit que REST est basé sur l'hypertexte. Je ne suis pas sûr qu'il ait raison, parce que / user / 123 est un URI qui pointe vers une ressource, et ce n'est pas clair pour moi que c'est unRESTful juste parce que le client le sait "out-of-band".

Ce document xfront explique la différence entre REST et SOAP, et c'est vraiment utile aussi. Quand Fielding dit, "C'est RPC. Il crie RPC.", il est clair que RPC n'est pas RESTful, donc il est utile de voir les raisons exactes de cela (SOAP est un type de RPC.)


43
2018-03-22 16:36



Qu'est-ce que REST?

REST dans les mots officiels, REST est un style architectural construit sur certains principes en utilisant les fondamentaux actuels "Web". Il y a 5 fondamentaux de base du web qui sont utilisés 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 est effectuée par représentation
  • Principe 5: Être apatride

36
2017-11-22 22:49