REST
Transfert d'état de représentation
REST est l'acronyme de Transfert d'état de représentation.
Qu’est ce qu' Transfert d'état de représentation?
Un style architectural pour concevoir des applications en réseau. Dans pratiquement tous les cas, il s'appuie sur un protocole de communication client-serveur sans état et pouvant être mis en cache, le HTTP protocole. L'idée derrière REST est de traiter toutes les ressources côté serveur comme des objets qui peuvent être créés, lus, mis à jour ou supprimés via un ensemble d'opérations définies. Ce concept s'aligne étroitement sur les opérations standard prises en charge par HTTP : POST, GET, PUT et DELETE.
Pourquoi cela s'appelle-t-il transfert d'état représentatif
Le terme Transfert d'état de représentation est choisi pour des raisons spécifiques :
- Représentatif fait référence aux représentations de ressources (le document ou l'objet que vous avez demandé au serveur) transférées sur le réseau. Le client peut facilement gérer ces représentations dans des formats tels que XML, JSONou YAML.
- Transfert d'État implique que chaque interaction client et serveur transfère un état. Lorsqu'un client demande une ressource, la réponse du serveur consiste essentiellement à transférer l'état de cette ressource au client. Ce transfert d'état permet à une application RESTful d'être sans état, ce qui signifie que chaque requête d'un client vers un serveur doit contenir toutes les informations nécessaires pour comprendre et compléter la requête. Le serveur ne stocke aucun état sur la session client côté serveur.
Principes de REST
REST repose sur plusieurs principes clés qui définissent sa simplicité et sa puissance :
- Apatride: Chaque requête du client au serveur doit contenir toutes les informations nécessaires pour comprendre et compléter la requête. Le serveur n'a pas d'état de session ; il est entièrement conservé du côté du client.
- Serveur client: Une interface uniforme sépare les clients des serveurs. Cette séparation des préoccupations prend en charge l'évolution indépendante de la logique côté client et du stockage de données côté serveur, améliorant ainsi la portabilité de l'interface client sur plusieurs plates-formes.
- Cacheable : Les réponses doivent se définir comme pouvant être mises en cache ou non pour empêcher les clients de réutiliser des données obsolètes ou inappropriées en réponse à d'autres demandes.
- Système en couches : Un client ne peut généralement pas savoir s'il est connecté directement au serveur final ou à un intermédiaire. Les serveurs intermédiaires peuvent améliorer l'évolutivité du système en permettant l'équilibrage de charge et en fournissant des caches partagés.
- Interface uniforme : Pour bénéficier des avantages de REST, les applications doivent adhérer à une interface uniforme. Cela implique généralement d'utiliser des méthodes HTTP standard de manière cohérente et de suivre des URL orientées ressources.
Exemple PHP
Créer une API RESTful en PHP implique de gérer les requêtes HTTP (GET, POST, PUT, DELETE) et de répondre avec des données dans un format comme JSON ou XML. Voici un exemple simplifié d'API RESTful en PHP qui gère une liste de tâches. Cet exemple montre la gestion des requêtes GET et POST pour plus de simplicité.
Ce PHP Cet exemple vous montrera comment créer deux points de terminaison : un pour récupérer la liste des tâches (GET /tasks
) et un autre pour ajouter une nouvelle tâche (POST /tasks
).
index.php
– Le point d’entrée
<?php
// Define a simple array of tasks as our "database"
$tasks = [
['id' => 1, 'title' => 'Buy groceries', 'completed' => false],
['id' => 2, 'title' => 'Finish homework', 'completed' => false]
];
// Get the request method
$requestMethod = $_SERVER['REQUEST_METHOD'];
// Simple router
switch ($requestMethod) {
case 'GET':
getTasks();
break;
case 'POST':
addTask();
break;
default:
// Handle other HTTP methods or return an error
header('HTTP/1.1 405 Method Not Allowed');
break;
}
function getTasks() {
global $tasks;
header('Content-Type: application/json');
echo json_encode($tasks);
}
function addTask() {
global $tasks;
$input = json_decode(file_get_contents('php://input'), true);
if (!isset($input['title']) || !isset($input['completed'])) {
header('HTTP/1.1 400 Bad Request');
echo json_encode(['message' => 'Missing title or completed status']);
return;
}
$newTask = [
'id' => end($tasks)['id'] + 1,
'title' => $input['title'],
'completed' => $input['completed']
];
$tasks[] = $newTask;
header('Content-Type: application/json');
echo json_encode($newTask);
}
?>
Processus Simplifié pour Assurer votre Conformité
- Ce script agit comme un simple point de terminaison d'API. Selon la méthode de requête HTTP, elle renvoie soit une liste de tâches (
GET
) ou ajoute une nouvelle tâche à la liste (POST
). - Pour
GET
demandes, il affiche simplement le$tasks
tableau au format JSON. - Pour
POST
requêtes, il lit la charge utile JSON à partir du corps de la requête (supposé contenirtitle
etcompleted
statut), ajoute une nouvelle tâche au$tasks
tableau et renvoie la nouvelle tâche au format JSON. - Cet exemple utilise un tableau global PHP comme base de données fictive. Dans une application réelle, vous interagirez probablement avec une base de données pour stocker et récupérer des tâches.
Tester l'API
Vous pouvez tester cette API à l'aide d'outils comme Postman ou cURL. Par exemple, pour ajouter une nouvelle tâche :
curl -X POST -H "Content-Type: application/json" -d '{"title":"Learn REST","completed":false}' http://localhost/index.php
Et pour obtenir la liste des tâches :
curl -X GET http://localhost/index.php
Il s'agit d'un exemple très basique destiné à illustrer le concept d'une API RESTful en PHP. Les scénarios du monde réel nécessiteraient un traitement plus robuste des requêtes, une gestion des erreurs et des considérations de sécurité telles que l'authentification et la validation des entrées.
- Abréviation: REST