REST vs RESTful vs service Web «normal»

21

J'ai lu quelques définitions et discussions sur les applications REST et / ou RESTful, mais je n'en comprends toujours pas le sens réel.

Je travaille généralement avec les applications qui récupèrent des données via GET ou envoient des données via POST à un service Web (généralement un script PHP) qui récupère ensuite les données de la base de données ou écrit dans la base de données.

Maintenant, est-ce une application RESTful? Sinon, quelle serait une application RESTful? Quelle est la différence entre le concept RESTful et le concept avec lequel j'ai travaillé jusqu'à présent? Veuillez expliquer par un exemple.

De plus, quelqu'un parle du REST et quelqu'un des applications RESTful. J'ai trouvé que le terme REST fait référence au concept théorique, tandis que RESTful est utilisé lorsque nous parlons de l'application spécifique. Est-ce vrai ou il existe de réelles différences entre les applications REST et RESTful?

— deviDave
source

1

Si vous pouvez créer tous vos servlets pour extraire des informations des paramètres GET ou POST UNIQUEMENT (absolument rien enregistré localement avant l'appel), alors vous appliquez correctement REST. En d'autres termes, le serveur joue le rôle du modèle dans MVC en ce qu'il n'est pas en contrôle mais utilise simplement ce qui est donné pour effectuer une tâche. J'espère que cela explique un peu mieux.

— Neil

@Neil Je suis de l'autre côté - application mobile. Il s'agit d'un client qui utilise le service Web et communique avec lui via POST et GET. Tous les services Web ont été créés par quelqu'un d'autre et je n'ai fait que les utiliser. Mais la terminologie m'a dérouté. Donc, si j'utilise le canal HTTP et les objets HttpGet / HttpPost, alors j'ai affaire à une application RESTful, non?

— deviDave

Pas nécessairement. Il n'y a aucun moyen de savoir s'il s'agit d'une application RESTful si vous ne savez pas comment le serveur fonctionne, car cela pourrait violer certaines contraintes. Cela dit, il est probablement RESTful s'il renvoie des résultats cohérents.

— Neil

@Neil Oh, je reçois maintenant. RESTful est effectué sur le serveur. Et si j'envoie un objet de publication avec une demande (pas chaque paramètre individuellement), c'est probablement une approche REST. En ce qui concerne un client (application mobile), peu importe que ce soit REST ou non car le codage est le même. Ai-je bien compris?

— deviDave

2

RESTful est à la fois serveur et client, mais si vous ne pouvez voir que le client, vous ne pouvez savoir que si le client respecte les contraintes. C'est tout ce que je voulais dire. Ce que je veux dire par REST, c'est que si vous devez vous connecter, vous publiez un nom d'utilisateur et un mot de passe. Le serveur valide la connexion et enregistre la clé de hachage de l'utilisateur dans la base de données et la renvoie. Désormais, chaque fois que vous devez effectuer une opération nécessitant une connexion, vous passez toujours la clé de hachage utilisateur. Le serveur «oublie» qu'il vous a connecté, mais utilise le hachage de l'utilisateur pour valider votre état de connexion. S'il n'était pas RESTful, le serveur se souviendrait que vous étiez connecté. Vous comprenez la différence?

— Neil

13

Les attributs clés des applications RESTful sont: Toutes les communications se font via http GET, POST, PUT, DELETE ET tous les éléments sont adressés via une URL standard du formulaire, http://your.site.com/salesapp/salesperson/0000001/detailsc'est-à-dire uniquement une URL pure sans paramètres, etc. L'URL identifie la chose que GET , POST, PUT, DELETE identifie ce que vous voulez y faire.

La principale raison pour cela est que vous disposez automatiquement d'un service sans état qui peut être équilibré en charge, basculé, etc., etc.

La simple simplicité du schéma permet une interface très propre, découplant totalement le client de toute implémentation back-end particulière.

— James Anderson
source

Oh, jusqu'à présent, je n'ai pas utilisé PUT ou DELETE (les applications mobiles ne font généralement que GET et POST), mais cela ressemble en effet à ce que j'ai fait et fais actuellement. C'est juste que les clients n'ont pas utilisé les termes REST *, mais plutôt "service web" et "script php"

— deviDave

2

James, pourriez-vous expliquer pourquoi les paramètres de requête doivent être évités? Par exemple, comment exprimer que je souhaite que les ressources soient filtrées d'une manière particulière sans introduire de fausse hiérarchie?

— Gary Rowe

3

@GaryRowe: L'URL (sans paramètre) identifie la ressource que vous souhaitez manipuler. Vous pouvez toujours avoir des paramètres mais ceux-ci ne sont pas utilisés pour identifier la ressource. Exemple un GET sur un répertoire (une URL se terminant par un /) devrait renvoyer une liste de ressources dans le répertoire. Un paramètre sur l'URL peut être utilisé pour spécifier un filtre ou un ordre de tri ou quelque chose comme ça.

— Martin York

1

Merci, Loki. James pourrait vouloir modifier sa réponse pour refléter cela, car il semble qu'il n'autorise pas l'utilisation des paramètres de requête dans des circonstances qui pourraient être trompeuses. En fait, il y a une observation intéressante que la liste des ressources dans un répertoire est en soi une ressource exprimant ce concept.

— Gary Rowe

REST ne nécessite pas que l'application soit basée sur une URL, ni ne nécessite que vous ayez des verbes comme GET, POST, DELETE, etc. Cependant, pour une WebApp, URL est la seule option et les verbes susmentionnés.

— Nawaz

6

REST signifie Representational State Transfer. Si votre logiciel est conforme aux contraintes REST, il est alors considéré comme RESTful.

Bon, maintenant que j'ai sans vergogne arraché de Wikipédia, qu'est-ce que cela signifie vraiment? Cela signifie effectivement utiliser les commandes HTTP intégrées telles que GET, POST, PUT, DELETE et quelques autres plus rares pour communiquer entre un client et un serveur.

Ce que vous faites ressemble à une application RESTFul. Cependant, il existe une grande différence entre des services Web RESTFul bien conçus et des piles de fichiers indésirables. Par exemple, le code PHP à l'autre extrémité du GET peut exécuter un changement d'état, ce qui serait considéré comme incorrect car un GET est considéré comme une opération en lecture seule. Il existe également de subtiles différences entre l'utilisation de POST (nouveau) et PUT (remplacement).

L'article de Wikipédia sur ce sujet est vraiment très bon, alors je m'arrête ici.

— Martijn Verburg
source

Jusqu'à présent, j'ai utilisé GET (HttpGet) pour récupérer le contenu et POST (HttpPost) pour entrer / modifier le contenu d'une base de données. J'ai envoyé cela en tant que paramètre à HttpPost et le script PHP sur le serveur Web a converti ces paramètres en code SQL. S'agit-il d'une application RESTful? Je m'intéresse à un concept, pas à la façon dont le script PHP a été fait. Je ne l'ai pas fait.

— deviDave

2

J'enquêterais sur l'utilisation de PUT dans le cas où vous remplacez du contenu, son REST plus idiomatique que de toujours utiliser POST.

— Martijn Verburg

Oui, dans ce cas, j'utiliserais PUT.

— deviDave

+1 pour avoir noté que GET doit être implémenté correctement (c'est-à-dire qu'il est idempotent). Une telle erreur fondamentale dans les premiers jours.

— Gary Rowe

@deviDave Vous voudrez peut-être aussi examiner PATCH qui a été conçu pour mettre à jour une partie d'une ressource. Comme Martin le souligne à juste titre, PUT est destiné à remplacer la totalité de la ressource.

— Gary Rowe

4

Avant d'aller plus loin, cette question connexe peut vous aider

La différence entre REST et RESTful est simplement sémantique. REST est un style architectural appliqué à une relation client-serveur. RESTful est simplement un moyen de dire à vos clients que vous utilisez REST.

De nombreuses applications Web prétendent être RESTful, mais ne sont en fait que partiellement conformes aux contraintes REST (comme Martijn Verburg l'a également mentionné dans sa réponse). Je vais simplement les énumérer ici, mais je vous invite fortement à lire l'article:

Serveur client
Cacheable
Système en couches
Code sur demande (facultatif)

Puisque vous mentionnez que vous travaillez du côté client, il peut être utile de voir ce qu'une architecture REST vous donnera et attendra de vous en tant que client connecté. Bien que REST ne soit pas HTTP, il est de loin le protocole le plus populaire qui prend en charge ce qu'est REST, je vais donc encadrer mon exemple autour de cela.

Votre client devra:

utiliser des verbes HTTP (par exemple GET, POST, PUT, DELETE, OPTIONS, PATCH) pour effectuer les opérations pertinentes
proposez des en-têtes Accept et comprenez les en-têtes Content-Type (par exemple, vous recevez du XML que vous n'avez jamais vu auparavant mais vous pouvez utiliser un XSD référencé pour créer un modèle de domaine côté client à présenter à votre utilisateur)
suivez les liens proposés dans un type de contenu que vous comprenez (par exemple, faites en sorte que votre utilisateur ou votre application infère qu'en <link rel="pay" href="http://example.org/orders(1)/payment">HTML exprime une transition d'état pour créer une ressource de paiement via un POST avec un corps contenant du XML qui représente les détails de paiement comme le numéro de carte de crédit , montant, etc.)
réagir correctement à la large gamme de codes d'état HTTP

S'il fait ce qui précède, il peut être considéré comme un client REST, vous pouvez l'appeler une «application RESTful», mais cela impliquerait plutôt que vous utilisez REST du côté client, ce qui est incorrect afin d'éviter le terme.

— Gary Rowe
source

3

RESTful signifie que l'interface est un ensemble d'objets, qui peuvent être lus et mis à jour (et éventuellement supprimés). Autrement dit, il n'y a pas de requêtes multi-paramètres (seul le paramètre est l'objet que vous souhaitez lire) et il n'y a qu'un seul type d'opération qui change quoi que ce soit sur le serveur, téléchargement d'un nouvel état.

Ces limitations garantissent que toutes les demandes sont idempotentes (les envoyer plusieurs fois n'a aucun effet supplémentaire à les envoyer une fois). Ceci est important, car le réseau peut échouer à tout moment et ne fournir aucune demande ou réponse et avec des demandes idempotentes, vous n'avez qu'à l'envoyer à nouveau et vous n'avez pas à effectuer une récupération compliquée.

— Jan Hudec
source

Vote positif pour le 1er paragraphe. Si concis. Merci!

— deviDave

Encore une chose, pour voir si j'ai bien compris. Si je (mon application) est un client du service REST, en tant que client, je ne me demande pas si un service est RESTful ou non car mon codage est toujours le même (httpget, httppost, etc.)? Ce principe ne concerne que le propriétaire d'un script / application serveur?

— deviDave

REST est un guide pour la conception de la sémantique de l'interface. La technologie sous-jacente est HTTP, que l'interface soit RESTful ou non (mais d'autres couches comme XML-RPC ou SOAP ne sont pas pertinentes pour les interfaces RESTful), vous utilisez donc toujours les mêmes httpget, httppost, etc. Mais vous gérez les pannes de réseau différemment.

— Jan Hudec

pour ajouter, SMTP est une interface RESTful, bien qu'il utilise différents verbes de GET, PUT, etc. et un protocole sous-jacent différent, le concept est le même - vous envoyez des commandes basées sur des verbes idempotents à un serveur.

— gbjbaanb

Toutes les demandes REST ne sont pas idempotentes. Par exemple, l'émission d'un POST plusieurs fois entraînera de nombreuses nouvelles ressources.

— Gary Rowe

REST vs RESTful vs service Web «normal» - le même ou pas?