ReSTful donc Stateless

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
👍
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

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

    • 


​