application REST
Je sais pas si je manque de connaissances de base en informatiques ou de points de QI, mais j'arrive pas a piger ce c'est qu'une application REST, pourquoi tout d'un coup on ne cause plus que de ca et a quoi ca s'oppose ... Une bonne ame saurait-elle m'éclairer ?
11 réponses
- Une application REST se focalise sur le principe créer / lire / updater / deleter. Bon, mais jusque la j'avais l'impression que c'est de toute façon ce que fait toute application web, non ?
En fait On peut dire que "tout" Internet est ReST. Quelque part, il n'y a pas vraiment d'autres actions possibles.
- Ou alors c'est plus dans la façon dont on communique avec l'appli qui fait qu'elle est REST ? (URL propres, qui utilisent les GET, POST, PUT, DELETE) ... en d'autres termes si j'utilise bien une methode POST pour créer une entrée dans ma bdd, mon appli est REST, mais si je transferts ma variable en GET pour créer cette même emtrée, elle n'est plus REST ?
L'url n'a (à mon sens) rien à voir avec ReST, cela va plutôt agir sur les API (j'en parlerai plus tard). ReST est défini par plusieurs points :
* L'utilisation du protocole HTTP (même si dans certains cas, on peut l'utiliser avec d'autres protocoles)
* La bonne utilisation des Requests Headers, Responses Headers et Status Codes de HTTP. Tu peux les voir en ouvrant un inspecteur Chrome sur Network et en analysant les requêtes HTTP.
* La requête doit être stateless, c'est à dire qu'à chaque connexion du client vers le serveur, le serveur est incapable de connaître l'état précédent du client.
- OUI MAIS: il me semblait que les méthodes PUT et DELETE étaient obsoletent ? Pourtant j'avais lu sur un post stackoverflow que ne serait-ce que mettre /objet/23/delete comme url n'est pas REST. Il faudrait faire /objet/23 avec une methode DELETE pour que ce le soit.
Il n'y a pas de standard ReST, plutôt des guidelines. L'important concerne principalement le point 2 et 3 de mon paragraphe cité plus haut. Certains frameworks n'utilisent pas PUT et DELETE en effet car ils estiment que l'on peut le faire avec un POST (ex : si je crée un article, j'envoie une requête POST avec mes informations pour la sauvegarde, pour éditer, j'envoie la même requête sauf que ce coup ci je possède l'id de l'article. Ca me permet de savoir si c'est un ajout ou une édition).
L'avantage principal de posséder les 4 méthodes va être lors de la gestion des urls justement.
- Le concept des ces url propres est aussi en vigueur depuis pas mal de temps, avec les framework etc ... pourquoi d'un coup tout cette vague REST ?
L'url propre est autre chose pour moi, même si certains accordent beaucoup d'importance à ce point dans le fait de dire qu'une application/API est ReST ou non.
L'avantage d'avoir les 4 méthodes (GET, POST, PUT, DELETE) va permettre de simplifier grandement les urls. Prenons le cas d'une gestion d'utilisateur.
version 1
Lecture de tous les utilisateur : GET http://www.exemple.com/users/
Lecture d'un utilisateur : GET http://www.exemple.com/users/1
Ajout d'un utilisateur : POST http://www.exemple.com/users/
Edition d'un utilisateur : PUT http://www.exemple.com/users/1
Suppression d'un utilisateur : DELETE http://www.exemple.com/users/1
Si on utilise que les méthodes GET et POST, on "casse" le principe de ReST car on introduit des verbes dans l'url. Pour certains cela fait que ce n'est plus ReST. C'est un peu trop restrictif à mon goût car on peut être dépendant du framework.
version 2
Lecture de tous les utilisateur : GET http://www.exemple.com/users/index/
Lecture d'un utilisateur : GET http://www.exemple.com/users/view/1
Ajout d'un utilisateur : POST http://www.exemple.com/users/edit/
Edition d'un utilisateur : POST http://www.exemple.com/users/edit/1
Suppression d'un utilisateur : POST http://www.exemple.com/users/delete/1
A l'heure actuelle, quasiment tous les frameworks ou SDK possèdent une implémentation complète des 4 méthodes donc la version 1
Les urls propres permettent surtout une homogénéité dans l'API, dans le sens ou je sais que si je veux récupérer les articles, je n'ai qu'à faire http://www.exemple.com/posts/, éditer une page : PUT http://www.exemple.com/pages/1, ...). La lecture et l'utilisation de l'API n'en est que plus simple.
- Disons que j'ai une appli simple, seulement un CRUD pour une série d'article que je veux vendre, ou autre ... que pourrais-je faire qui rende mon application non-RESTful ?
Par exemple, tu peux renvoyer un mauvais code d'erreur. C'est ce que fait Facebook dans leur API, ils renvoient en permanence 200 OK, même si la page n'existe pas (404) par exemple. L'erreur est ensuite défini dans le corps de la requête. De ce fait on peut considérer que leur API n'est plus ReSTful.
On peut voir que le concept de ReST / non ReST est encore vague car certains articles se contredisent. A mon sens l'url ne devrait pas autant être prise en compte dans le fait que l'application soit ReST/non ReST, d'autres considèrent que si.
Plus de lecture :
http://www.lornajane.net/posts/2013/five-clues-that-your-api-isnt-restful
http://zoom.it/pages/api/formats/rest-vs-non-rest
http://stackoverflow.com/questions/2191049/what-is-the-advantage-of-using-rest-instead-of-non-rest-http
Les bonnes pratiques pour une construire son API.
http://ciar.org/ttk/public/apigee.web_api.pdf
Exemple d'API.
https://github.com/kippt/api-documentation
Ca tombe bien, j'ai toujours eu un peu de mal avec ce mot "REST".
Ce que je sais, c'est que ça a un rapport avec les verbes HTTP. Ca utilise GET, PUT, POST et DELETE pour respectivement lire, mettre à jour, insérer et supprimer qqchose dans la base.
Un controlleur REST ressemblerait donc à ça :
class UserController extends BaseController {
public function getIndex()
{
//
}
public function postProfile()
{
//
}
}Bien sur ce n'est pas une réponse complète que je te propose mais c'est tout ce que je sais :)
Selon wikipédia, il y aurait d'autres paramètres en jeu comme "la mise en cache", "un système séparé en couche"...
Si une âme charitable pouvait éteindre les phares de la voiture REST qui éblouit les lapins comme Vallyan et moi, ce serait sympa :D
Salut,
j'ai déjà donné un début de réponse ici :
http://www.grafikart.fr/forum/topic/12065.
http://www.grafikart.fr/forum/topic/11642 (un peu plus hors sujet par contre).
Je m'attarderai plus en détail sur les différents points s'il y a encore des questions.
OK, j'ai relu ces liens mais je les avais globalement en tête lorsque j'ai posé la question. Je vais préciser les points qui me titillent:
-
Une application REST se focalise sur le principe créer / lire / updater / deleter. Bon, mais jusque la j'avais l'impression que c'est de toute façon ce que fait toute application web, non ?
-
Ou alors c'est plus dans la façon dont on communique avec l'appli qui fait qu'elle est REST ? (URL propres, qui utilisent les GET, POST, PUT, DELETE) ... en d'autres termes si j'utilise bien une methode POST pour créer une entrée dans ma bdd, mon appli est REST, mais si je transferts ma variable en GET pour créer cette même emtrée, elle n'est plus REST ?
-
OUI MAIS: il me semblait que les méthodes PUT et DELETE étaient obsoletent ? Pourtant j'avais lu sur un post stackoverflow que ne serait-ce que mettre /objet/23/delete comme url n'est pas REST. Il faudrait faire /objet/23 avec une methode DELETE pour que ce le soit.
-
Le concept des ces url propres est aussi en vigueur depuis pas mal de temps, avec les framework etc ... pourquoi d'un coup tout cette vague REST ?
-
Disons que j'ai une appli simple, seulement un CRUD pour une série d'article que je veux vendre, ou autre ... que pourrais-je faire qui rende mon application non-RESTful ?
Merci en tous cas prbaron ^^
OK OK, je comprends déja nettement mieux.
On peut donc utiliser les méthodes PUT et DELETE comme on utiliserait les GET et POST ? Je demande parce que je lisais que HTML5 ne les uspportait pas (ils sont supporté sur mon framework, par contre ...)
http://stackoverflow.com/a/16812862/1795767
En tous cas excellente explication, merci d'avoir pris le temps !
On peut donc utiliser les méthodes PUT et DELETE comme on utiliserait les GET et POST ? Je demande parce que je lisais que HTML5 ne les uspportait pas (ils sont supporté sur mon framework, par contre ...)
En effet, PUT et DELETE ne sont pas supporté par les navigateurs web. Mais ce n'est pas la seule façon de communiquer avec un serveur. Si tu utilises un téléphone par exemple, dans une application native, tu peux avoir accès à des librairies HTTP plus complètes.