COURS SUR LES API REST

SOMMAIRE
1. Introduction aux API REST
2. Principes fondamentaux

3. Méthodes HTTP et ressources

4. Structure des requêtes et réponses

5. Bonnes pratiques de conception

6. Sécurité des API REST

7. Technologies d'implémentation

8. Tests et documentation

9. Conclusion

1. INTRODUCTION AUX API REST

1.1 Définition
Une API REST (Representational State Transfer) est un style d'architecture pour la conception
d'applications en réseau, principalement utilisé pour créer des services web.

1.2 Historique
Introduit par Roy Fielding dans sa thèse de doctorat en 2000

Développé comme une alternative aux protocoles complexes comme SOAP et RPC
Adoption massive à partir de 2005-2010 avec l'essor du web 2.0

1.3 Importance des API REST

Facilite l'intégration entre systèmes hétérogènes
Permet le développement d'architectures orientées services

Soutient les applications web et mobiles modernes

Fondement des microservices et architectures distribuées

2. PRINCIPES FONDAMENTAUX

2.1 Architecture client-serveur

Séparation claire entre le client et le serveur, permettant une évolution indépendante.

2.2 Sans état (Stateless)

Chaque requête du client vers le serveur doit contenir toutes les informations nécessaires pour
comprendre et traiter la requête.

2.3 Mise en cache

Les réponses doivent indiquer si elles peuvent être mises en cache pour améliorer les performances.

2.4 Interface uniforme

Composée de quatre contraintes:

Identification des ressources

Manipulation des ressources via des représentations

Messages auto-descriptifs

HATEOAS (Hypermedia as the Engine of Application State)

2.5 Système en couches

Architecture hiérarchique où chaque composant ne peut "voir" que la couche avec laquelle il interagit
directement.

2.6 Code à la demande (facultatif)

Possibilité d'étendre les fonctionnalités du client en téléchargeant du code exécutable.

3. MÉTHODES HTTP ET RESSOURCES

3.1 Les principales méthodes HTTP

Méthode Description Idempotence

GET Récupérer des données Oui

POST Créer une ressource Non

PUT Mettre à jour une ressource (complète) Oui

PATCH Mettre à jour une ressource (partielle) Non

DELETE Supprimer une ressource Oui

HEAD Comme GET sans le corps de réponse Oui

OPTIONS Obtenir les méthodes supportées Oui

 

3.2 Ressources et URIs

Les ressources sont le concept clé de REST

Chaque ressource est identifiée par un URI

Structure hiérarchique recommandée

 Exemple: /utilisateurs/123/commandes/456

3.3 Collections et éléments

Collections: /utilisateurs

Éléments spécifiques: /utilisateurs/123

Relations: /utilisateurs/123/commandes

3.4 Opérations CRUD

Opération Méthode HTTP URI

Create POST /utilisateurs

Read GET /utilisateurs/123

Update PUT/PATCH /utilisateurs/123

Delete DELETE /utilisateurs/123

 

4. STRUCTURE DES REQUÊTES ET RÉPONSES

4.1 Requêtes HTTP

GET /api/utilisateurs/123 HTTP/1.1

Host: exemple.com
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

4.2 Réponses HTTP

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=3600

{
"id": 123,
"nom": "Dupont",
"email": "[email protected]"
}

4.3 Codes de statut HTTP

 Catégorie Description Exemples

2xx Succès 200 OK, 201 Created, 204 No Content

3xx Redirection 301 Moved Permanently, 304 Not Modified

4xx Erreur client 400 Bad Request, 401 Unauthorized, 404 Not Found

5xx Erreur serveur 500 Internal Server Error, 503 Service Unavailable
 

4.4 Formats de données

JSON (JavaScript Object Notation) - le plus courant

XML (eXtensible Markup Language)

YAML (YAML Ain't Markup Language)

HTML (HyperText Markup Language)

4.5 Pagination, filtrage et tri

Pagination: ?page=2&size=10

Filtrage: ?status=active&category=electronics

Tri: ?sort=price,desc

5. BONNES PRATIQUES DE CONCEPTION

5.1 Nommage des ressources

Utiliser des noms et non des verbes

Préférer le pluriel pour les collections

Utiliser des noms en minuscules

Utiliser des tirets ( - ) plutôt que des underscores ( _ )

5.2 Versionnement des API

Approches possibles:

Dans l'URL: /api/v1/utilisateurs

Dans l'en-tête: Accept: application/vnd.entreprise.v1+json

Paramètre de requête: ?version=1.0

5.3 Gestion des erreurs

Utiliser les codes de statut HTTP appropriés

Fournir des messages d'erreur clairs

Inclure des identifiants d'erreur pour le débogage

 Structure cohérente des réponses d'erreur

json

{
"status": 400,
"message": "Validation failed",
"errors": [
{"field": "email", "message": "Invalid email format"}
],
"error_id": "5d2da1c4-1a6b-4f5d-8823-5a5e8f2fd5e7"
}

5.4 Documentation des API

Utilisation de standards comme OpenAPI/Swagger

Documentation du comportement des endpoints

Exemples de requêtes et réponses

Description des modèles de données

5.5 HATEOAS
Hypermedia as the Engine of Application State - inclusion de liens dans les réponses:

json

{
"id": 123,
"nom": "Dupont",
"_links": {
"self": {"href": "/utilisateurs/123"},
"commandes": {"href": "/utilisateurs/123/commandes"},
"modifier": {"href": "/utilisateurs/123", "method": "PUT"}
}
}

6. SÉCURITÉ DES API REST

6.1 Authentification
Basic Authentication

OAuth 2.0 / OpenID Connect

Jetons JWT (JSON Web Tokens)

API Keys
6.2 Autorisation
Contrôle d'accès basé sur les rôles (RBAC)

Contrôle d'accès basé sur les attributs (ABAC)

Scopes OAuth

6.3 Protections contre les attaques courantes

Injection SQL: Validation et paramétrage des requêtes

Cross-Site Scripting (XSS): Échappement des données

Cross-Site Request Forgery (CSRF): Jetons anti-CSRF

Rate Limiting: Limitation du nombre de requêtes

HTTPS: Chiffrement des communications

6.4 Validation des données

Validation des entrées côté serveur

Schémas JSON pour la validation structurelle

Sanitisation des données

7. TECHNOLOGIES D'IMPLÉMENTATION

7.1 Frameworks côté serveur

Node.js: Express, Nest.js, Fastify

Java: Spring Boot, Jersey, Quarkus

Python: Flask, Django REST framework, FastAPI

PHP: Laravel, Symfony

.NET: ASP.NET Core Web API

7.2 Outils de développement

Postman / Insomnia: Test des API

Swagger / OpenAPI: Documentation et tests

JSONPlaceholder: API fictive pour le prototypage

cURL: Tests en ligne de commande

7.3 Monitoring et analytics

API Gateways: Kong, Apigee, Amazon API Gateway

New Relic / Datadog: Surveillance des performances

 Prometheus / Grafana: Métriques et visualisation

8. TESTS ET DOCUMENTATION

8.1 Types de tests

Tests unitaires: Validation de la logique métier

Tests d'intégration: Validation des interactions entre composants

Tests fonctionnels: Validation du comportement de l'API

Tests de charge: Validation des performances sous charge

8.2 Outils de test

Jest, Mocha: Tests JavaScript
JUnit, TestNG: Tests Java

PyTest: Tests Python

REST Assured, SuperTest: Tests d'API REST

8.3 Documentation interactive

Swagger UI

ReDoc
Postman Collections

API Blueprint

8.4 Contrats d'API

OpenAPI Specification (anciennement Swagger)

API Blueprint

RAML (RESTful API Modeling Language)

9. CONCLUSION

9.1 Avantages des API REST

Simplicité et familiarité

Indépendance de la technologie
Scalabilité et fiabilité

Large adoption et soutien communautaire

9.2 Limites et alternatives

 GraphQL: Requêtes flexibles, récupération précise des données
gRPC: Haute performance, contrats stricts avec Protocol Buffers

WebSockets: Communication bidirectionnelle en temps réel

9.3 Tendances futures

AsyncAPI pour les API asynchrones

API composites et Federation

API serverless
API Event-Driven

RÉFÉRENCES ET RESSOURCES
1. Roy Fielding, "Architectural Styles and the Design of Network-based Software Architectures", 2000

2. Leonard Richardson, Sam Ruby, "RESTful Web Services", O'Reilly Media

3. Martin Fowler, "Richardson Maturity Model",

https://martinfowler.com/articles/richardsonMaturityModel.html
4. Specification OpenAPI: https://swagger.io/specification/

5. "REST API Design Rulebook", Mark Masse

6. Mozilla Developer Network (MDN): https://developer.mozilla.org/fr/docs/Web/HTTP

© 2025 - Cours sur les API REST