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
