Une RESTful Architecture
Communauté .NET Montréal
Une RESTful Architecture
@brisebois runatserver.com
Alexandre Brisebois
Développeur Sénior
Runatserver
Montréa
l
Web ● Touch ● Mobile ●
Training
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
Bénéfices
Portabilité
Scalability
Evolvability
Visibilité
Fiabilité
Efficacité
Performance
Manageability
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é
Une interface uniforme
Identification de ressources
Manipulation via représentations
Message Auto-descriptifs
Hypermedia as the engine of
application state (HATEOAS)
Les different
niveaux de REST
1
2 3
0
1
2
3
Ressources
Verbes HTTP
Hypermédia
POX0
Le chemin vers
REST tel que décris
par Leonard
Richardson
POX (Plain Old XML)
0101110101010010100101001001
101001001001000100100101010
1010010010010010010010111101
1010010010111011010010101010
1
2
3
Ressources
Verbes HTTP
Hypermédia
POX0
Le chemin vers
REST tel que décris
par Leonard
Richardson
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
1
2
3
Ressources
Verbes HTTP
Hypermédia
POX0
Le chemin vers
REST tel que décris
par Leonard
Richardson
Verbes HTTP
GET
POST
PUT
DELETE
HEAD
PATCH
Titre présentation
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
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
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
Hypermédia en HTML
Hypermédia en Json
HAL (Hypertext Application Language)
HAL (Hypertext Application Language)
Hypermédia en Json
Hypermédia en XML
HAL (Hypertext Application Language)
http://stateless.co/hal_specification.html
http://hal.codeplex.com/
https://github.com/robdmoore/Hal.PlayAro
und
HAL (Hypertext Application Language)
Démo
Trouver l’erreur!
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
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
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
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
C’est possible
Une RESTful Architecture
@brisebois runatserver.com
Alexandre Brisebois
Développeur Sénior
Runatserver
Montréa
l
Web ● Touch ● Mobile ●
Training

Une RESTful Architecture