Quelle est la bonne façon de faire du repos?

36

Aujourd'hui, tout le monde fait de la SOA , même si certains ne comprennent pas vraiment de quoi il s'agit. Alors ils le font mal. En utilisant cette analogie, je sais ce que REST est (ou du moins je pense que je connais) et je veux en faire une partie. Mais je veux bien faire les choses.

Ma question est donc quelle est la bonne façon de faire REST?

JohnDoDo
la source
1
Le wiki de la balise 'reste' de Stack Overflow semble être aussi proche que possible d'une ressource canonique dans le contexte du réseau Stack Exchange
gnat
17
Je viens de fermer les yeux pendant un moment ... peut-être aller faire un tour à vélo puis me coucher.
Edward Strange
REST n’utilise-t-il pas fondamentalement une URL telle que mydomain.com/accounts et un verbe HTTP pour appeler une opération? Où le verbe indique si vous souhaitez obtenir, créer, mettre à jour ou supprimer des données? Quand je pense que le repos est ce que je pense.
Le muffin homme
2
@ Nick, c'est l'interprétation la plus courante, la "vraie chose" est beaucoup plus difficile à maîtriser et (autant que je sache) beaucoup plus difficile à trouver réellement implémentée où que ce soit ... (voir la réponse de Wilk)
Benjol
3
@Nick, votre compréhension n'est pas REST, c'est RPC sur HTTP .

Réponses:

30

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

Wilk
la source
1
Vous pourriez envisager d'ajouter ce lien , qui est le guide le plus complet que j'ai rencontré.
Benjol
J'ai vu PUT et POST utilisés avec leurs significations permutées (par rapport à votre réponse): POST -> créer, PUT -> mettre à jour. Avez-vous une idée du sens le plus utilisé?
Andres F.
@Andres F .: jcalcote.wordpress.com/2008/10/16/… dit: Create = PUT si et seulement si vous envoyez le contenu complet de la ressource spécifiée (URL). Create = POST si vous envoyez une commande au serveur pour créer un subordonné de la ressource spécifiée, à l'aide d'un algorithme côté serveur. Update = PUT si et seulement si vous mettez à jour le contenu complet de la ressource spécifiée. Update = POST si vous demandez au serveur de mettre à jour un ou plusieurs subordonnés de la ressource spécifiée.
Wilk
@Benjol: Je vais éditer avec votre suggestion;) Merci!
Wilk
1
@Wilk Quelques points à considérer! Pourquoi personne ne le comprend si bien: P
Andres F.
5

un livre de bible REST ou quelque chose ....

Aucun livre biblique n'est nécessaire. J'avais les mêmes questions et j'ai appris tout ce dont j'avais besoin ou tout ce que je voulais savoir sur REST en lisant ces trois articles:

  1. Introduction du débutant à HTTP et REST de Net Tuts +
  2. Services Web RESTful: notions de base d'IBM developerWorks
  3. RESTful HTTP en pratique à partir d'InfoQ

Mais je veux bien faire les choses.

Comme vous le lirez dans les articles ci-dessus, il est essentiel de considérer les éléments accessibles de votre application comme des "ressources" pouvant être créées, récupérées, mises à jour ou supprimées à l'aide des "verbes" HTTP existants: GET, PUT, POST. , SUPPRIMER.

Vous devez également connaître la différence entre PUT et POST et savoir quand les utiliser. GET, PUT, and DELETE doivent être des transactions idempotentes, pas POST.

En outre, utilisez correctement les codes d'état HTTP lors de la communication avec le client.

CFL_Jeff
la source