Comprendre le concept de REST pour développer efficacement ses applications
REST, ou Representational State Transfer, est un style architectural utilisé pour concevoir des services web qui optimisent les relations entre les clients et les serveurs. Développé par Roy Fielding en 2000, REST est devenu une norme incontournable pour les applications web modernes. Il se base sur des principes simples pour rendre les communications entre les clients et les serveurs plus fluides et efficaces.
Lorsqu’on explore le développement d’APIs, comprendre les principes de REST est essentiel pour concevoir des services web efficaces et cohérents. Cet article devrait vous guider à travers les concepts clés qui définissent REST, comme les ressources et URI, les méthodes HTTP, et les principes comme le statelessness (sans état) et la mise en cache. Vous découvrirez également l’importance d’un système en couches et d’une interface uniforme dans la conception d’APIs.
Ces principes permettent de créer des APIs robustes et évolutives qui facilitent la communication entre les clients et les serveurs. Nous explorerons chacun de ces aspects pour vous fournir une vue d’ensemble complète et pratique de REST.
Au cœur de REST se trouvent des principes essentiels qui simplifient la création et l’utilisation des API. Dans cet article, nous allons explorer ces concepts clés :
- les ressources et leurs URI,
- les méthodes HTTP,
- d’autres méthodes HTTP,
- les avantages d’utiliser des méthodes appropriées,
- ainsi que des principes fondamentaux tels que
- le Statelessness,
- la Cacheability,
- le Système en Couches,
- et l’Interface Uniforme.
Ressources et URI dans REST
Dans une API REST, une ressource est simplement un élément ou une donnée que vous souhaitez manipuler via votre application. Cela pourrait être une tâche, un utilisateur, un produit, etc. Pensez à une ressource comme un « objet » ou un « sujet » que vous pouvez créer, lire, mettre à jour ou supprimer.
Une URI (Uniform Resource Identifier) est une sorte d’adresse unique qui permet de localiser cette ressource sur le web. C’est comme l’adresse d’une maison : elle vous indique où trouver quelque chose. Dans le contexte de REST, l’URI est l’adresse que vous utilisez pour accéder à une ressource spécifique.
Imaginez que vous développez une application pour gérer des tâches (une to-do list). Dans cette application, chaque tâche est une ressource. Supposons que vous avez une tâche avec l’identifiant 1
. Pour accéder aux détails de cette tâche spécifique, vous utiliseriez une URI.
Voici comment cela pourrait se présenter :
- URI de la ressource tâche :
https://api.example.com/taches/1
Dans cet exemple :
https://api.example.com
est la base de votre API./taches
indique que vous cherchez une ressource de type « tâche »./1
est l’identifiant de la tâche spécifique que vous voulez consulter.
Ainsi, en tapant cette URI dans un navigateur ou en envoyant une requête à cette adresse via votre application, vous demandez au serveur de vous donner les informations sur la tâche avec l’identifiant 1
.
L’idée clé ici est que chaque ressource dans une API REST a sa propre adresse (URI), ce qui permet de la manipuler facilement via des méthodes HTTP (comme GET pour la lire, POST pour en créer une nouvelle, etc.). Cela rend les interactions avec les données claires et structurées. Justement abordons les méthodes à disposition.
Les Méthodes HTTP dans REST
Dans le cadre des APIs REST, les méthodes HTTP définissent les actions à réaliser sur des ressources, comme des tâches dans une application de gestion. En plus de spécifier l’action, il est souvent nécessaire de transmettre des paramètres pour personnaliser la requête. Voyons comment cela fonctionne en pratique.
Récupérer des données avec GET
La méthode GET
est utilisée pour consulter des informations. Supposons que vous voulez récupérer uniquement les tâches qui sont marquées comme « complètes ». Vous pourriez ajouter un paramètre à votre requête, comme ceci :
fetch('https://api.example.com/taches?status=complet');
Dans cet exemple, le paramètre status=complet
est ajouté à l’URL pour filtrer les résultats. Côté serveur, en PHP, vous récupérerez ce paramètre avec la superglobale $_GET
$status = $_GET['status']; // Récupère la valeur 'complet'
Ensuite, vous pourriez utiliser cette valeur pour ajuster votre requête SQL ou votre logique de traitement.
Créer de nouvelles ressources avec POST
Lorsque vous créez une nouvelle ressource, comme une tâche, vous pouvez passer des paramètres dans le corps de la requête. Par exemple, pour ajouter une nouvelle tâche avec un titre et une description, vous ferez une requête POST
fetch('https://api.example.com/taches', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ title: 'Nouvelle tâche', description: 'Faire le ménage' })
});
Les paramètres title
et description
sont envoyés dans le corps de la requête. Côté serveur, en PHP, vous récupérerez ces données via la superglobale $_POST
$title = $_POST['title']; // 'Nouvelle tâche'
$description = $_POST['description']; // 'Faire le ménage'
Pour les requêtes AJAX utilisant fetch
, il est souvent plus simple de décoder les données JSON comme ceci
$data = json_decode(file_get_contents('php://input'), true);
$title = $data['title'];
$description = $data['description'];
Mettre à jour une ressource existante avec PUT
La méthode PUT
permet de mettre à jour des ressources existantes. Disons que vous voulez changer le statut d’une tâche existante avec l’identifiant 1
. Voici comment passer les paramètres avec fetch
fetch('https://api.example.com/taches/1', {
method: 'PUT',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ status: 'en cours' })
});
Ici, le paramètre status
est passé dans le corps de la requête pour mettre à jour l’état de la tâche. Contrairement à POST
, où les données sont récupérées via la superglobale $_POST
, avec PUT
, les données ne sont pas automatiquement placées dans cette superglobale. Côté PHP, vous devez utiliser le flux php://input
pour lire les données brutes envoyées dans le corps de la requête. Vous pouvez ensuite les décoder et les traiter ainsi
// Lire les données brutes du corps de la requête PUT
$putData = file_get_contents('php://input');
// Convertir les données JSON en tableau associatif
$data = json_decode($putData, true);
// Récupérer le paramètre 'status'
$status = $data['status'] ?? null;
Avec cette approche, vous pouvez mettre à jour des champs spécifiques dans votre base de données ou autre stockage.
Supprimer une ressource avec DELETE
Pour supprimer une ressource, comme une tâche spécifique, vous utiliserez la méthode DELETE
. Par exemple, pour supprimer la tâche avec l’identifiant 1
et peut-être un autre paramètre de sécurité, voici comment structurer la requête
fetch('https://api.example.com/taches/1', {
method: 'DELETE',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ confirmation: 'oui' })
});
Dans cet exemple, le paramètre confirmation
est envoyé dans le corps de la requête DELETE
pour s’assurer que l’action de suppression est bien intentionnelle. En PHP, la récupération des données envoyées dans une requête DELETE
(ou PUT
) ne se fait pas via les superglobales habituelles comme $_POST
, mais plutôt à l’instar de PUT, en lisant directement les données brutes à partir du flux php://input
. Voici comment vous pouvez le faire
// Lire les données brutes du corps de la requête DELETE
$inputData = file_get_contents('php://input');
// Convertir les données JSON en tableau associatif
$data = json_decode($inputData, true);
// Récupérer le paramètre 'confirmation' en vérifiant qu'il est bien présent
$confirmation = $data['confirmation'] ?? null;
if ($confirmation === 'oui') {
// Procéder à la suppression de la tâche
// Code pour supprimer la tâche...
} else {
// Gérer le cas où la confirmation n'est pas donnée
// Code pour gérer l'absence de confirmation...
}
Cette méthode garantit que seules les requêtes valides et intentionnelles aboutissent à la suppression d’une ressource
D’autres méthodes HTTP et leur utilité en REST
En plus des méthodes HTTP couramment utilisées dans les API REST telles que GET
, POST
, PUT
, et DELETE
, il existe d’autres méthodes HTTP avec des usages spécifiques. Bien que moins fréquentes dans les API RESTful, elles jouent un rôle important dans certaines situations.
HEAD
La méthode HEAD
est très similaire à GET
, mais ne retourne que les en-têtes de la réponse, sans le corps du message. Cela peut être utile pour vérifier l’existence d’une ressource ou pour obtenir des métadonnées sans télécharger l’intégralité de son contenu. Par exemple, si vous souhaitez vérifier si un document existe sur un serveur sans le télécharger et obtenir des informations, vous pouvez envoyer une requête HEAD
fetch('https://api.example.com/documents/rapport.pdf', {
method: 'HEAD'
})
.then(response => {
console.log('Content-Type:', response.headers.get('Content-Type'));
console.log('Content-Length:', response.headers.get('Content-Length'));
});
Côté serveur, vous ne devez pas traiter la méthode HEAD
différemment de GET
, sauf pour ne pas envoyer de corps de réponse. Vous pouvez ajouter une condition pour vérifier la méthode
if ($_SERVER['REQUEST_METHOD'] === 'HEAD') {
// Envoi seulement des en-têtes, pas de corps
header('Content-Type: application/pdf');
header('Content-Length: ' . filesize('documents/rapport.pdf'));
}
OPTIONS
La méthode OPTIONS
est utilisée pour découvrir les méthodes HTTP supportées par le serveur pour une ressource donnée. C’est souvent utilisé pour vérifier les permissions CORS. Voir notre article CORS ou la Gestion des Requêtes Cross-Origin.
fetch('https://api.example.com/taches/1', {
method: 'OPTIONS'
})
.then(response => response.headers.forEach((value, name) => console.log(`${name}: ${value}`)));
Côté serveur, vous pouvez répondre avec les méthodes autorisées en utilisant les en-têtes appropriés
if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE');
header('Access-Control-Allow-Headers: Content-Type');
exit;
}
CONNECT
La méthode CONNECT
est utilisée pour établir un tunnel HTTP, souvent pour des connexions sécurisées via un proxy. Elle n’est pas typiquement utilisée dans les APIs REST.
// `CONNECT` n'est pas utilisé directement en JavaScript côté client
Vous ne traitez généralement pas les requêtes CONNECT
dans un contexte REST. Les serveurs proxy et les serveurs de niveau inférieur gèrent cette méthode.
Supposons que vous souhaitiez établir une connexion HTTPS à un serveur web via un proxy HTTP. Vous utiliseriez la méthode CONNECT
pour demander au proxy d’ouvrir un tunnel sécurisé vers le serveur cible. Voici comment vous formuleriez la requête HTTP pour établir ce tunnel
CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com
Où et Comment Envoyer Ce Code ?
Serveur Proxy : La méthode CONNECT
est généralement utilisée par un serveur proxy. Vous ne l’envoyez pas directement depuis un script JavaScript ou PHP, mais vous configurez un serveur proxy pour gérer ces requêtes. Vous pouvez utiliser des outils comme curl
pour tester ce comportement, ou configurer un proxy qui gère les requêtes CONNECT
.
Utilisation Pratique : En pratique, les clients configurent souvent leurs navigateurs ou applications pour utiliser un proxy qui gère automatiquement ces requêtes. Pour des tests ou des démonstrations, vous pouvez utiliser des outils de ligne de commande comme curl
curl -x http://proxyserver:port -L --proxy-tunnel https://www.example.com
Dans cet exemple, curl
envoie la requête CONNECT
via le proxy spécifié et établit le tunnel vers www.example.com
.
Serveur Proxy PHP : Si vous êtes responsable de la configuration d’un serveur proxy ou d’un service proxy en PHP, vous écririez du code pour gérer les requêtes CONNECT
. Cela impliquerait d’utiliser des bibliothèques réseau en PHP, comme montré dans l’exemple de code pour un serveur proxy de base en Node.js.
En résumé, la méthode CONNECT
est gérée par le serveur proxy ou des outils réseau pour établir des tunnels sécurisés. Vous ne l’envoyez pas directement depuis les scripts côté client, mais vous pouvez tester ou configurer des environnements de développement en utilisant des outils comme curl
ou en configurant des serveurs proxy.
TRACE
La méthode TRACE
est utilisée pour le débogage en renvoyant la requête reçue par le serveur. Elle est rarement utilisée en production en raison des risques de sécurité.
fetch('https://api.example.com/taches/1', {
method: 'TRACE'
})
.then(response => response.text().then(text => console.log(text)));
Pour traiter les requêtes TRACE
, vous pouvez renvoyer la requête exacte
if ($_SERVER['REQUEST_METHOD'] === 'TRACE') {
header('Content-Type: text/plain');
echo file_get_contents('php://input');
}
PATCH
La méthode PATCH
permet de mettre à jour partiellement une ressource. Elle est utile pour modifier seulement certaines parties d’une ressource sans la remplacer entièrement.
fetch('https://api.example.com/taches/1', {
method: 'PATCH',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ status: 'completed' })
})
.then(response => response.json())
.then(data => console.log(data));
Côté serveur, vous lisez les données de la requête et appliquez les modifications nécessaires
if ($_SERVER['REQUEST_METHOD'] === 'PATCH') {
$inputData = file_get_contents('php://input');
$data = json_decode($inputData, true);
// Supposons que vous avez une fonction pour mettre à jour la tâche
$status = $data['status'] ?? null;
if ($status) {
// Mettre à jour la tâche en base de données
// Exemple : updateTaskStatus(1, $status);
}
echo json_encode(['status' => 'success']);
}
PATCH
peut sembler similaire à PUT
, mais alors que PUT
remplace entièrement une ressource existante avec les nouvelles données fournies, PATCH
ne modifie que les parties spécifiques de la ressource.
Ces exemples montrent comment chaque méthode HTTP peut être utilisée dans des contextes spécifiques et comment elles peuvent être traitées côté serveur en PHP. En comprenant ces méthodes, vous pouvez concevoir des APIs RESTful plus robustes et adaptées à divers besoins.
Les Avantages d’Utiliser les Méthodes HTTP Appropriées
Il est courant de voir des développeurs utiliser uniquement GET
et POST
pour toutes les actions, même pour les mises à jour ou les suppressions, souvent en raison de la simplicité ou des limitations des formulaires HTML. Cependant, cela peut conduire à des pratiques non standard et compliquer la compréhension et la gestion de l’API. En respectant les conventions REST, vous créez des interfaces plus robustes et conformes aux meilleures pratiques du développement d’APIs.
Utiliser les méthodes HTTP appropriées (GET
, POST
, PUT
, DELETE
) présente plusieurs avantages importants :
Sécurité et Validation : L’utilisation des bonnes méthodes HTTP peut améliorer la sécurité et la validation des requêtes. Par exemple, en utilisant DELETE
, vous pouvez facilement inclure des mécanismes de confirmation pour éviter les suppressions accidentelles, tandis que PUT
permet de cibler précisément les ressources à mettre à jour.
Clarté et Convention : Chaque méthode HTTP a une signification précise et une utilisation conventionnelle. En suivant ces conventions, votre API est plus facile à comprendre et à utiliser, tant pour les développeurs que pour les utilisateurs finaux. Cela réduit la confusion et rend l’API plus intuitive.
Sémantique et Fonctionnalité : En utilisant GET
pour lire des données, POST
pour créer, PUT
pour mettre à jour, et DELETE
pour supprimer, vous assurez que chaque action est traitée de manière appropriée et efficace. Cela permet à votre API de respecter les principes REST, ce qui peut améliorer la gestion des erreurs et le traitement des données.
Maintenabilité : Une API qui utilise les méthodes HTTP correctes est généralement plus facile à maintenir et à étendre. Les développeurs peuvent rapidement comprendre ce que fait chaque requête et comment elle est censée fonctionner, ce qui facilite l’ajout de nouvelles fonctionnalités ou la correction de bugs.
En conclusion, en utilisant GET
, POST
, PUT
, et DELETE
avec des paramètres spécifiques, vous pouvez affiner vos requêtes et interactions avec le serveur. Côté client, les requêtes AJAX en JavaScript passent ces paramètres dans l’URL pour GET
, ou dans le corps de la requête pour POST
, PUT
, et DELETE
. Côté serveur, PHP récupère ces données via $_GET
, $_POST
, ou php://input
selon la méthode utilisée. Cela permet de gérer efficacement les ressources dans une application web, qu’il s’agisse de filtrer les données, de créer de nouvelles entrées, de mettre à jour des éléments existants ou de supprimer ce qui n’est plus nécessaire.
Les Statuts de Réponse HTTP : Comprendre les Codes de Réponse
Lorsqu’une requête est envoyée à un serveur via une API, le serveur répond avec un code de statut HTTP qui indique le résultat de la demande. Ces codes jouent un rôle essentiel en signalant le succès ou l’échec de l’opération.
Par exemple, si vous demandez les détails d’une tâche et que tout se passe bien, vous recevrez un code 200 OK
, signifiant que la requête a réussi. En revanche, demander une tâche inexistante retournera un code 404 Not Found
, indiquant que la ressource est introuvable. De même, si votre requête pour créer une nouvelle tâche est incorrecte, un code 400 Bad Request
sera renvoyé pour signaler une erreur dans la requête.
Cependant, ni les langages comme PHP ni les serveurs web ne gèrent ces codes de manière automatique. Lorsqu’un code comme 404
ou 500
est renvoyé, il n’y a pas de mécanisme intégré pour fournir des explications détaillées ou gérer l’erreur. C’est au développeur de configurer comment ces codes seront traités, soit par des pages d’erreur personnalisées via .htaccess
, soit par des scripts PHP ou JavaScript. Cette gestion manuelle permet de personnaliser la réponse en fonction des besoins spécifiques de l’application.
Les Principes Fondamentaux de REST : Statelessness, Cacheability, Système en Couches, et Interface Uniforme
REST repose sur plusieurs principes clés qui garantissent une architecture efficace et scalable pour les services web. Ces principes aident à créer des APIs qui sont non seulement faciles à utiliser mais aussi robustes et performantes. Voici un aperçu de ces principes essentiels :
Statelessness (Sans État)
L’un des principes fondamentaux de REST est le statelessness ou l’absence d’état. Cela signifie que chaque requête envoyée au serveur doit contenir toutes les informations nécessaires pour comprendre et traiter la demande. Le serveur ne doit pas conserver d’informations sur l’état des requêtes précédentes.
Par exemple, si vous faites une demande pour obtenir les détails d’une tâche, vous devez inclure toutes les informations nécessaires dans cette requête, comme l’identifiant de la tâche. Cela simplifie le design du serveur, qui n’a pas à gérer ou à mémoriser des sessions ou des états clients. En PHP, cela signifie que chaque requête est indépendante et que les données doivent être extraites et traitées à partir de la requête elle-même
$taskId = $_GET['id']; // Récupère l'identifiant de la tâche depuis la requête GET
Cacheability (Mise en Cache)
Le principe de cacheability concerne la capacité des réponses à être mises en cache. Les réponses des serveurs doivent inclure des informations permettant aux clients et aux intermédiaires de savoir si et comment la réponse peut être mise en cache. La mise en cache améliore les performances en réduisant le besoin de faire des requêtes répétitives au serveur.
Par exemple, si vous demandez la liste des tâches, et que les résultats ne changent pas fréquemment, le serveur peut indiquer que la réponse est cacheable. En ajoutant des en-têtes HTTP comme Cache-Control
, le serveur informe le client ou les proxies intermédiaires de conserver cette réponse pendant un certain temps
Cache-Control: max-age=3600
En PHP, vous pouvez envoyer cet en-tête comme suit
header('Cache-Control: max-age=3600'); // Indique que la réponse peut être mise en cache pendant 1 heure
Système en Couches (Layered System)
Le principe du système en couches stipule que l’architecture d’un service web REST peut être organisée en couches, où chaque couche a une responsabilité spécifique. Cela permet de séparer les préoccupations et de créer une architecture plus modulaire et flexible.
Par exemple, dans un système en couches, vous pouvez avoir une couche pour la présentation, une autre pour la logique métier, et une autre encore pour l’accès aux données. Cette séparation facilite le développement, le test, et la maintenance des différentes parties de l’application. Côté serveur, vous pouvez structurer vos applications en différentes couches de cette manière
// Exemple de séparation des responsabilités
// Couche de contrôle
function getTask($taskId) {
return TaskService::findById($taskId);
}
// Couche de service
class TaskService {
public static function findById($taskId) {
return TaskRepository::getById($taskId);
}
}
// Couche de données
class TaskRepository {
public static function getById($taskId) {
// Code pour accéder à la base de données
}
}
Interface Uniforme (Uniform Interface)
Le principe de l’interface uniforme exige que l’interface entre les clients et le serveur soit uniforme et cohérente. Cela signifie que les APIs doivent suivre des conventions et des normes qui facilitent leur utilisation et leur compréhension.
Par exemple, une API REST devrait utiliser des URIs cohérents pour accéder aux différentes ressources et des méthodes HTTP standard (GET
, POST
, PUT
, DELETE
) pour effectuer des opérations. Cela permet aux développeurs de comprendre rapidement comment interagir avec l’API, indépendamment de l’application qu’ils utilisent.
En JavaScript, vous pouvez utiliser ces méthodes de manière uniforme pour accéder aux ressources
// Utilisation uniforme des méthodes HTTP
// Lire une tâche
fetch('https://api.example.com/taches/1', { method: 'GET' });
// Créer une nouvelle tâche
fetch('https://api.example.com/taches', { method: 'POST', body: JSON.stringify({ title: 'Nouvelle tâche' }) });
En PHP, cela se traduit par l’utilisation d’une structure cohérente pour traiter les différentes requêtes
if ($_SERVER['REQUEST_METHOD'] === 'GET') {
// Traiter une requête GET
} elseif ($_SERVER['REQUEST_METHOD'] === 'POST') {
// Traiter une requête POST
}
Ces principes permettent de garantir que les APIs REST sont non seulement bien conçues mais également performantes, maintenables, et évolutives. En les appliquant correctement, vous pouvez construire des services web qui répondent aux besoins des utilisateurs tout en respectant les meilleures pratiques du développement d’APIs.
En conclusion, et en résumé, pourquoi Utiliser REST ?
REST est devenu un choix incontournable pour la conception des APIs en raison de sa simplicité, de sa flexibilité, et de sa compatibilité avec les standards du web. Mais pourquoi devriez-vous choisir REST pour vos propres projets ? Voici quelques raisons convaincantes :
Simplicité et Facilité de Mise en Œuvre
L’un des principaux avantages de REST réside dans sa simplicité. REST utilise les méthodes HTTP standard (comme GET
, POST
, PUT
, DELETE
), ce qui permet aux développeurs de travailler avec des concepts qu’ils connaissent déjà. Contrairement à d’autres architectures plus complexes, REST ne nécessite pas de protocole ou de bibliothèque spéciale pour commencer. Vous pouvez construire une API RESTful en utilisant les technologies web de base, ce qui en fait un excellent choix pour les projets de toute taille.
Flexibilité et Scalabilité
REST est extrêmement flexible. Il peut être utilisé avec presque tous les langages de programmation, et il est agnostique par rapport aux formats de données — bien que JSON soit souvent préféré pour sa légèreté et sa compatibilité. Cette flexibilité permet aux APIs RESTful de s’adapter facilement aux besoins changeants d’une application. De plus, REST est conçu pour être scalable. En respectant les principes de REST, tels que le statelessness et le système en couches, il est possible de créer des services web capables de gérer une grande charge de travail sans compromettre les performances.
Interopérabilité et Compatibilité
REST repose sur des standards web bien établis comme HTTP, ce qui le rend interopérable avec une multitude de systèmes et de technologies. Que vous développiez pour le web, le mobile, ou des systèmes embarqués, REST s’intègre parfaitement dans ces environnements. Les APIs RESTful peuvent être consommées par n’importe quel client HTTP, qu’il s’agisse de navigateurs web, d’applications mobiles, ou même d’autres services web. Cette compatibilité en fait un excellent choix pour les projets nécessitant une interaction avec diverses plateformes.
Efficacité et Performance
En suivant les principes REST, vous pouvez construire des APIs qui sont non seulement simples à utiliser mais aussi efficaces. Par exemple, en utilisant la mise en cache (cacheability), vous pouvez réduire la charge sur le serveur en permettant aux clients de stocker temporairement des réponses. De plus, en adoptant une interface uniforme, vous garantissez une utilisation cohérente et optimisée des ressources. Les statuts de réponse HTTP permettent également d’assurer une communication claire entre le client et le serveur, réduisant ainsi les erreurs et améliorant la performance globale.
Large Adoption et Support
Enfin, REST bénéficie d’une large adoption dans l’industrie. De nombreuses grandes entreprises, comme Google, Facebook, et Twitter, utilisent REST pour leurs APIs publiques. Cela signifie que vous avez accès à une vaste communauté de développeurs, à des ressources pédagogiques abondantes, et à des outils bien supportés pour vous aider dans le développement de vos propres services RESTful. De plus, REST étant un standard de facto, il est facile de trouver des développeurs avec les compétences nécessaires pour travailler sur des projets basés sur REST.