1. Une RESTful Architecture
Communauté .NET Montréal

2. Une RESTful Architecture
@brisebois runatserver.com
Alexandre Brisebois
Développeur Sénior
Runatserver
Montréa
l
Web ● Touch ● Mobile ●
Training

3. REpresentational state transfer
N’est PAS
• RPC
oREST n’est pas pour faire des appels a des
méthodes via le réseau
• HTTP
o Même si vous utiliser HTTP comme protocole de
communication, il se peut que votre service ne soit
pas RESTful
• URIs
oLes URIs propres ne sont pas un prérequis de
REST

4. Bénéfices
Portabilité
Scalability
Evolvability
Visibilité
Fiabilité
Efficacité
Performance
Manageability

5. Forces de REST
Peut palier au manque de fiabilité du réseau
Peut réduire les temps de latence
Peut réduire la bande passante utiliser
Peut simplifier la sécurité
Résiste a une Topologie du réseau changeante
Peut distribue l’administration
Peut réduire les couts de transport
Peut vivre dans un réseaux non hétérogènes
Peut réduit Complexité

6. Une interface uniforme
Identification de ressources
Manipulation via représentations
Message Auto-descriptifs
Hypermedia as the engine of
application state (HATEOAS)

7. Les different
niveaux de REST
1
2 3
0

8. 1
2
3
Ressources
Verbes HTTP
Hypermédia
POX0
Le chemin vers
REST tel que décris
par Leonard
Richardson

9. POX (Plain Old XML)
0101110101010010100101001001
101001001001000100100101010
1010010010010010010010111101
1010010010111011010010101010

10. 1
2
3
Ressources
Verbes HTTP
Hypermédia
POX0
Le chemin vers
REST tel que décris
par Leonard
Richardson

11. Ressources
http://localhost/api/tasks
http://localhost/api/tasks/(?id)
http://localhost/api/tasks/backlog
http://localhost/api/tasks/in-progress
http://localhost/api/tasks/completed
Mappe un concept nommé à un ensemble d'entités dans le temps
Relation plusieurs à plusieurs entre les concepts et les entités
La relation peut être stable dans le temps, ou il peut changer
fréquemment

12. 1
2
3
Ressources
Verbes HTTP
Hypermédia
POX0
Le chemin vers
REST tel que décris
par Leonard
Richardson

13. Verbes HTTP
GET
POST
PUT
DELETE
HEAD
PATCH
Titre présentation

14. A REST API should be entered with no
prior knowledge beyond the initial URI
(bookmark) and set of standardized
media types that are appropriate for the
intended audience (i.e., expected to be
understood by any client that might use the
API). From that point on, all application
state transitions must be driven by
client selection of server-provided
choices that are present in the received
representations or implied by the user’s
manipulation of those representations. The
transitions may be determined (or limited
by) the client’s knowledge of media types
and resource communication mechanisms,
both of which may be improved on-the-fly
(e.g., code-on-demand).
~ Roy Fielding

15. 1
2
3
Ressources
Verbes HTTP
Hypermédia
0 POX
Seulement le niveau
3 peut être
considérer comme
REST
Le chemin vers
REST tel que décris
par Leonard
Richardson

16. Hypermédia
Est la partie de REST qui est le plus
souvent oublier
Réduit le couplage entre le server et le
client en réduisant le nombre de URI
connue par le client
L’hypermédia est l’aspet qui différencie
REST de RPC

17. Hypermédia en HTML

18. Hypermédia en Json

19. HAL (Hypertext Application Language)

20. HAL (Hypertext Application Language)

21. Hypermédia en Json

22. Hypermédia en XML

23. HAL (Hypertext Application Language)
http://stateless.co/hal_specification.html
http://hal.codeplex.com/
https://github.com/robdmoore/Hal.PlayAro
und

24. HAL (Hypertext Application Language)
Démo

25. Trouver l’erreur!

26. Characteristics recherché
Ils suivent les normes
Le style est constant et prévisible
Leur URI font ce qu'ils disent
Il retourne des Code HTTP pour
communiquer des erreurs

27. Characteristics recherché
Il ne maintienne pas d’état et il sont
rapide
Les PUTs sont omnipotent
Ils retournent uniquement les données
nécessaires
Ils implémenter la pagination pour les
longues listes

28. Characteristics recherché
Ils sont entièrement testés
Leurs interfaces sont bien
documentées
Leur documentation est toujours tenu à
jour
Idéalement, ils retournent des
messages légers comme json ou
protobuf

29. Characteristics recherché
Ils sont versionnés
Limiter les régression au maximum
Une fois qu'un endpoint est publié, il
est préférable de créer un nouveau
endpoint que de changer la signature
d'un endpoint existant.
Les lignes directrices ressemblent
fortement à celles du code propre

30. C’est possible

31. Une RESTful Architecture
@brisebois runatserver.com
Alexandre Brisebois
Développeur Sénior
Runatserver
Montréa
l
Web ● Touch ● Mobile ●
Training