Une RESTful Architecture

828 vues

Publié le

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
828
Sur SlideShare
0
Issues des intégrations
0
Intégrations
41
Actions
Partages
0
Téléchargements
24
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Une RESTful Architecture

  1. 1. Une RESTful ArchitectureCommunauté .NET Montréal
  2. 2. Une RESTful Architecture@brisebois runatserver.comAlexandre BriseboisDéveloppeur SéniorRunatserverMontréalWeb ● Touch ● Mobile ●Training
  3. 3. REpresentational state transferN’est PAS• RPCoREST n’est pas pour faire des appels a desméthodes via le réseau• HTTPo Même si vous utiliser HTTP comme protocole decommunication, il se peut que votre service ne soitpas RESTful• URIsoLes URIs propres ne sont pas un prérequis deREST
  4. 4. BénéficesPortabilitéScalabilityEvolvabilityVisibilitéFiabilitéEfficacitéPerformanceManageability
  5. 5. Forces de RESTPeut palier au manque de fiabilité du réseauPeut réduire les temps de latencePeut réduire la bande passante utiliserPeut simplifier la sécuritéRésiste a une Topologie du réseau changeantePeut distribue l’administrationPeut réduire les couts de transportPeut vivre dans un réseaux non hétérogènesPeut réduit Complexité
  6. 6. Une interface uniformeIdentification de ressourcesManipulation via représentationsMessage Auto-descriptifsHypermedia as the engine ofapplication state (HATEOAS)
  7. 7. Les differentniveaux de REST12 30
  8. 8. 123RessourcesVerbes HTTPHypermédiaPOX0Le chemin versREST tel que décrispar LeonardRichardson
  9. 9. POX (Plain Old XML)010111010101001010010100100110100100100100010010010101010100100100100100100101111011010010010111011010010101010
  10. 10. 123RessourcesVerbes HTTPHypermédiaPOX0Le chemin versREST tel que décrispar LeonardRichardson
  11. 11. Ressourceshttp://localhost/api/taskshttp://localhost/api/tasks/(?id)http://localhost/api/tasks/backloghttp://localhost/api/tasks/in-progresshttp://localhost/api/tasks/completedMappe un concept nommé à un ensemble dentités dans le tempsRelation plusieurs à plusieurs entre les concepts et les entitésLa relation peut être stable dans le temps, ou il peut changerfréquemment
  12. 12. 123RessourcesVerbes HTTPHypermédiaPOX0Le chemin versREST tel que décrispar LeonardRichardson
  13. 13. Verbes HTTPGETPOSTPUTDELETEHEADPATCHTitre présentation
  14. 14. A REST API should be entered with noprior knowledge beyond the initial URI(bookmark) and set of standardizedmedia types that are appropriate for theintended audience (i.e., expected to beunderstood by any client that might use theAPI). From that point on, all applicationstate transitions must be driven byclient selection of server-providedchoices that are present in the receivedrepresentations or implied by the user’smanipulation of those representations. Thetransitions may be determined (or limitedby) the client’s knowledge of media typesand resource communication mechanisms,both of which may be improved on-the-fly(e.g., code-on-demand).~ Roy Fielding
  15. 15. 123RessourcesVerbes HTTPHypermédia0 POXSeulement le niveau3 peut êtreconsidérer commeRESTLe chemin versREST tel que décrispar LeonardRichardson
  16. 16. HypermédiaEst la partie de REST qui est le plussouvent oublierRéduit le couplage entre le server et leclient en réduisant le nombre de URIconnue par le clientL’hypermédia est l’aspet qui différencieREST de RPC
  17. 17. Hypermédia en HTML
  18. 18. Hypermédia en Json
  19. 19. HAL (Hypertext Application Language)
  20. 20. HAL (Hypertext Application Language)
  21. 21. Hypermédia en Json
  22. 22. Hypermédia en XML
  23. 23. HAL (Hypertext Application Language)http://stateless.co/hal_specification.htmlhttp://hal.codeplex.com/https://github.com/robdmoore/Hal.PlayAround
  24. 24. HAL (Hypertext Application Language)Démo
  25. 25. Trouver l’erreur!
  26. 26. Characteristics recherchéIls suivent les normesLe style est constant et prévisibleLeur URI font ce quils disentIl retourne des Code HTTP pourcommuniquer des erreurs
  27. 27. Characteristics recherchéIl ne maintienne pas d’état et il sontrapideLes PUTs sont omnipotentIls retournent uniquement les donnéesnécessairesIls implémenter la pagination pour leslongues listes
  28. 28. Characteristics recherchéIls sont entièrement testésLeurs interfaces sont biendocumentéesLeur documentation est toujours tenu àjourIdéalement, ils retournent desmessages légers comme json ouprotobuf
  29. 29. Characteristics recherchéIls sont versionnésLimiter les régression au maximumUne fois quun endpoint est publié, ilest préférable de créer un nouveauendpoint que de changer la signaturedun endpoint existant.Les lignes directrices ressemblentfortement à celles du code propre
  30. 30. C’est possible
  31. 31. Une RESTful Architecture@brisebois runatserver.comAlexandre BriseboisDéveloppeur SéniorRunatserverMontréalWeb ● Touch ● Mobile ●Training

×