ReSTful donc Stateless

Stateless ?

Supposons le scénario d’échange suivant. Est-il stateless ?
🧐
👍
1
GET /init
2
GET /select-cart?cartId=123ab
3
POST /add-product
4
POST /add-product
5
POST /update-product-count?productId=12345
6
GET /cart-summary
7
POST /pay
Copied!
No!

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

1
POST /carts/123ab/items
2
POST /carts/456cb/items
3
PATCH /items/33333
4
POST /carts/123ab/payments
5
GET /carts/123ab
Copied!

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
Dernière mise à jour 2yr ago