API REST

Au sein d’une organisation N-tiers, l’API REST fait office de frontière entre les tiers : le frontend dialogue avec le backend au moyen d’URL, de verbes HTTP et de codes de statut, tandis que l’intérieur du backend reste structuré en MVC (contrôleur qui reçoit la requête, service qui porte la logique, repository qui accède aux données).

En contexte monolithique, les couches de l’application communiquent surtout en interne par appels de méthodes, mais l’API REST demeure le contrat exposé vers l’extérieur (applications web ou mobiles, intégrations). On garde la même discipline MVC à l’intérieur du monolithe pour préserver la clarté du code et préparer d’éventuelles évolutions. En architecture microservices, chaque service expose sa propre API (souvent REST) et peut aussi échanger par événements ; chacun conserve son mini-MVC en interne. On conserve la même discipline MVC pour garder un code clair et préparer d’éventuelles évolutions. En architecture microservices, chaque service expose sa propre API (souvent REST) et peut aussi échanger par événements ; chacun conserve son mini-MVC en interne.

Qu’est-ce qu’une API ?

Une API est un contrat d’échange : un ensemble de endpoints/fonctions, leurs signatures, et règles d’usage pour obtenir un résultat. Le but est de séparer les responsabilités client/serveur afin d’améliorer portabilité et évolutivité (le client peut évoluer sans casser le serveur, et inversement).

REST vs SOAP

Il existe actuellement deux types d’architecture très utilisée pour les APIs :

• Simple Object Access Protocol (SOAP)
• Representational State Transfer (REST).

En bref : REST privilégie la simplicité et l’usage naturel d’HTTP ; SOAP apporte un cadre très formel utile quand on a besoin de standards WS-* et de contrats XML stricts.

Les bases de REST

Le principe stateless

• Le serveur ne mémorise pas de contexte entre deux appels.
• Chaque requête contient tout le nécessaire (auth, paramètres, corps).
• Avantage : scalabilité (répartition sur plusieurs serveurs sans affinité).

Verbes HTTP et CRUD

Exemples (équipements)

• GET /api/equipements → liste paginée
• GET /api/equipements/{id} → détail
• POST /api/equipements → créer
• PATCH /api/equipements/{id} → modifier partiellement
• DELETE /api/equipements/{id} → supprimer

Les codes de statut HTTP (réponses)