# ReSTful donc Stateless

## Stateless ?

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

{% tabs %}
{% tab title="🧐" %}

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

{% endtab %}

{% tab title="👍" %}
![No!](https://392424868-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LFGxD_EMfiDhYN7-EXe%2F-LFHax-Xv0w-lpFzYJ-r%2F-LFHc9byHnBum0PIt9eL%2Fno.jpg?alt=media\&token=b9ccc6ea-af3e-4e10-b21b-1014e874ab24)
{% endtab %}
{% endtabs %}

## 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.<br>
* 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
  * …