Présentation
Les API RESTful sont souvent confondues avec les API REST, mais il existe une nuance importante. REST (Representational State Transfer) est un style d'architecture défini par Roy Fielding en 2000, qui impose des contraintes spécifiques. Les API RESTful doivent suivre ces principes pour être considérées comme telles.
Architecture REST
L'architecture REST repose sur six contraintes : la séparation du client et du serveur, l'étatlessness, la mise en cache, le système en couches, l'interface uniforme et le code sur demande (facultatif). Ces contraintes visent à créer une interface prévisible et standardisée pour les ressources.
HATEOAS et hypermédia
HATEOAS (Hypermedia as the Engine of Application State) est un concept fondamental pour les API RESTful. Il permet aux clients de découvrir dynamiquement les ressources via des liens fournis dans les réponses. Les liens sont généralement placés sous un parent _links. Par exemple :
{"id": 123, "name": "John Doe", "_links": {"self": {"href": "/users/123", "method": "GET"}, "update": {"href": "/users/123", "method": "PUT"}, "delete": {"href": "/users/123", "method": "DELETE"}}}Règles d'une API RESTful
Les API RESTful doivent suivre six règles définies par Fielding. La première règle est de ne pas dépendre d'un seul protocole, mais d'utiliser des identificateurs de ressources (URI) pour définir les ressources. La deuxième règle est de ne pas modifier le protocole, mais de suivre les conventions existantes. Les autres règles concernent la mise en cache, le système en couches, l'interface uniforme et le code sur demande.
