Eh bien, il y a beaucoup de façons d'apprendre à créer une application Web RESTful et non, il n'y a pas de bonne façon unique. RESTful n'est pas un standard, mais il utilise un ensemble de standards (HTTP, URI, Type Mime, ...).
Commencez avec ceci: Comment j'ai expliqué le reste à ma femme
Ensuite, procédez comme suit : Livre de recettes des services Web RESTful
Et mettez ensuite tous vos efforts à développer des applications Web, car la meilleure façon d'apprendre consiste à faire des expériences et vous pouvez apprendre beaucoup de vos erreurs;)
Ne vous inquiétez pas si vos premières applications Web ne seront pas complètement RESTful: vous trouverez le moyen de le faire!
Ainsi, citant Obi-Wan Kenobi, "que la force soit avec vous!" ;)
MODIFIER
Ok, laissez-moi être plus précis.
Vous voulez faire une webapp RESTful, hein? Comme je l’ai dit, il existe de nombreuses façons de le faire, mais c’est la ligne directrice principale.
Définition
REST (Representational State Transfer) est le style d'une architecture logicielle pour système distribué (comme WWW). Ce n'est pas un standard, mais il utilise un ensemble de standards: HTTP, AJAX, HTML, URI, Type Mime, etc. Nous parlons de la représentation d'une ressource, pas d'une ressource elle-même. Tiré de 'Comment j'ai expliqué REST à ma femme':
Femme : Une page Web est une ressource?
Ryan : En quelque sorte. Une page Web est une représentation d'une ressource. Les ressources ne sont que des concepts.
Contraintes de l'architecture
- Client-serveur : le client et le serveur sont séparés par l'interface uniforme (décrite ci-dessous).
- Sans état : la communication client-serveur est réalisée sans enregistrer un état client particulier sur le serveur.
- Cachable : le client peut avoir un cache de réponses de requêtes déjà faites.
- Système en couches : le client ne sait pas s'il est directement connecté à un serveur final ou si la communication se fait via des intermédiaires.
Interface uniforme
- Identification des ressources : chaque ressource doit être identifiée par un URI.
- Protocole : pour entrer en communication client et serveur, un protocole doit être fait avant. Chaque demande peut avoir le bon type MIME (application / xml, text / html, application / rdf + xml, etc.), les bons en-têtes et la bonne méthode HTTP (voir la description de CRUD ci-dessous).
CRUD
Ok, nous avons vu que pour identifier les ressources, nous pouvons utiliser l’URI, mais nous avons besoin de quelque chose d’autre pour les actions (ajouter, modifier, supprimer, etc.): bienvenue à CRUD (Créer, Lire, Mettre à jour et Supprimer).
- Créer { HTTP: POST } { SQL: INSERT } => créer une nouvelle ressource
- Lire { HTTP: GET } { SQL: SELECT } => obtenir une ressource
- Mettre à jour { HTTP: PUT } { SQL: UPDATE } => modifier une ressource
- Delete { HTTP: DELETE } { SQL: DELETE } => supprimer une ressource
Maintenant, en ce qui concerne PUT et DELETE, des problèmes techniques peuvent apparaître (vous les aurez avec le formulaire HTML): souvent les développeurs contournent ce problème en utilisant POST pour chaque requête 'PUT' et 'DELETE'. Officiellement, vous devez utiliser PUT et DELETE. Au fait, fais ce que tu veux. Mon expérience me pousse à utiliser POST et GET à chaque fois.
--- La partie suivante devrait être utilisée mais ce n'est pas un lien REST: il s'agit de données liées ---
URI
URI abstrait à partir de détails techniques! Dites au revoir à l'URI comme suit:
http://www.example.com/index.php?query=search&id=9823&date=08272012
Re-design URI! Prenez le lien ci-dessus et changez-le comme suit:
http://www.example.com/search/2012/08/27/9823
C'est beaucoup mieux, hein? Cela pourrait être fait par:
Autre chose: utiliser différents URI pour représenter différentes ressources:
Faites attention : about.html et about.rdf ne sont pas des fichiers! Ils pourraient être le résultat d'une transformation XSLT!
Négociation de contenu
Si vous avez atteint ce point, félicitations! Vous êtes probablement prêt à obtenir des concepts plus abstraits, car nous entrons dans les détails techniques du Web sémantique;) Eh bien, lorsque votre client souhaite une ressource, il effectue généralement la requête suivante:
GET http://www.example.com/about
Accept: application/rdf+xml
Mais le serveur ne répondra pas avec le about.rdf car il a un autre URI ( http://www.example.com/about.rdf ). Alors jetons un coup d'œil au motif 303 ! Le serveur retournera ceci:
303 See Other
Location: http://www.example.com/about.rdf
Et le client suivra le lien renvoyé comme suit:
GET http://www.example.com/about.rdf
Accept: application/rdf+xml
Enfin, le serveur retournera la ressource demandée:
200 OK
about.rdf
Ne vous inquiétez pas: votre application client ne fera rien de tout cela! Le modèle 303 doit être effectué par l’application serveur et votre navigateur se chargera du reste;)
Conclusion
Souvent, la théorie est loin, très loin de la pratique. Oui, vous savez maintenant comment concevoir et développer une application RESTful, mais les instructions ci-dessus ne sont qu'un indice. Vous trouverez votre meilleur moyen de créer des applications Web et ce ne sera probablement pas la même chose que le souhaite la théorie. Ne vous en foutez pas: D!
Bibliographie
Services Web RESTful, Sameer Tyagi
Les API REST doivent être gérées par l'hypertexte, Roy Thomas Fielding
Services Web RESTful: les bases, Alex Rodriguez
Flux de travail Webber REST