Le Guide API ReST | Marmicode
  • Le Guide API ReST par Marmicode
  • API ReST
    • L'Ecosystème Moderne
    • Le Besoin
    • Re.S.T. : REpresentational State Transfer
    • Les 5 règles et ½ de l’API ReST
    • Le Modèle de Maturité de Richardson
    • H.A.T.E.O.A.S. & Resource Linking
    • Avis Subjectif sur H.A.T.E.O.A.S. et le Semantic Web
    • ReST over HTTP
    • HTTP & CRUD
    • ReSTful donc Stateless
    • Pragmatisme, Idéologie et ReSTafarians
  • Conventions & Bonnes Pratiques
    • Nommage
    • Base URL
    • Media Type
    • Versioning
    • Propriété “id”
    • Polymorphisme
    • Datetime
    • Ressource d'Association
    • Pourquoi Appliquer ces Bonnes Pratiques
    • Zalando ReSTful API Guidelines
  • Les Outils
    • Swagger
    • OpenAPI Visual Editors
    • IDE Plugins
    • Postman
    • Insomnia
    • Fake & Sandbox
    • JSON Generator
    • Pact
  • Sécurité des APIs ReST
    • OWASP Top 10
    • Authentification et Session Management
    • Autorisation et Gestion des Permissions
    • Validation, Canonicalization, Escaping & Sanitization
    • Cookies are EVIL
    • C.O.R.S.
    • C.S.R.F.
    • C.S.R.F. & Media Type
    • C.S.R.F. Mitigation
    • C.S.R.F. & "Resource Linking"
    • J.O.S.E.
      • J.W.K.
      • J.W.S.
      • J.W.E.
    • J.W.T.
      • Description et Fonctionnement de JWT
      • Usages et Avantages
      • Utilisation de JWT pour l’Authentification
      • JWT, Authentification, Sessions et Risques Sécurité
      • Recommandations JWT
    • OAuth 2
      • OAuth 2 Roles
      • OAuth 2 Abstract Flow
      • OAuth 2 Authorization Code Flow
      • OAuth 2 Implicit Flow
      • OAuth 2 Resource Owner Password Credentials Flow
      • OAuth 2 Client Credentials
      • OAuth 2 Registration
      • OAuth 2 Risques & Recommandations
      • OAuth 2 Substitution Attack
    • OpenID Connect
      • Terminologie
      • Quoi de Neuf ?
      • OpenID Connect Flows
      • Que Faire ?
  • Autres Spécifications
    • JSON API
    • H.A.L.
    • JSON LD
    • Les Autres Initiatives
    • So What?
  • Quelques Liens & Ressources
  • Stay Tuned
    • 📝Blog
    • 🐦Twitter
    • 📬Newsletter
Propulsé par GitBook
Sur cette page
  • Stateless ?
  • Limites et Difficultés du Stateful
  • Exemple Stateless
  • Les Avantages de l'Approche Stateless
  1. API ReST

ReSTful donc Stateless

PrécédentHTTP & CRUDSuivantPragmatisme, Idéologie et ReSTafarians

Dernière mise à jour il y a 5 ans

Stateless ?

Supposons le scénario d’échange suivant. Est-il stateless ?

GET /init
GET /select-cart?cartId=123ab
POST /add-product
POST /add-product
POST /update-product-count?productId=12345
GET /cart-summary
POST /pay

Limites et Difficultés du Stateful

  • L’effet "never-click-back!".

  • Problèmes de "load balancing".

  • Comment paralléliser l’ajout de deux produits dans deux paniers différents ?

  • Comment mettre la ressource "/cart-summary" en cache.

  • API peu intuitive et peu extensible.

Exemple Stateless

POST /carts/123ab/items
POST /carts/456cb/items
PATCH /items/33333
POST /carts/123ab/payments
GET /carts/123ab

Les Avantages de l'Approche Stateless

  • Pas de session à maintenir et donc pas de problème de load balancing.

  • Moins de requêtes.

  • Il est possible de paralléliser les requêtes.

  • Cacheable.

  • API intuitive et extensible.

    • L’API est human readable (pas besoin d’avoir la documentation en permanence sous les yeux).

    • L’API est facile à étendre (ajout de propriétés par exemple).

    • L’API peut répondre facilement à des besoins qui n’ont pas été anticipé (modification du nombre de produits dans le panier par exemple).

En général, on peut comparer les approches stateful et stateless à la métaphore de la destination géographique.

Exemple :

  • Coordonnées GPS d'un lieu. vs.

  • Les indications pour s'y rendre :

    • Tournez à droite.

    • à 100m à gauche.

    • Au rond-point (s’il n’a pas changé depuis), sortez à la 3ème sortie.

    • Admirez la vue sur votre gauche

    • …

No!