Slim, API, Framework – Les bonnes pratiques pour créer une API avec le micro-framework PHP Slim

Il s’agit de comprendre rapidement comment concevoir puis de coder “grosses mailles” une API.

Les objectifs de cette expérience étaient les suivants :

1. Découvrir les principes et les meilleures pratiques possibles pour concevoir une API.
2. Choisir un micro framework ou petit framework pour réaliser ce prototype d’API afin d’avoir un exemple fonctionnel au bout d’une seule itération.
3. Appliquer à la lettre un principe de la méthode “lean” : lancer au plus vite une réalisation même imparfaite dont la fonction première est de servir de base à la discussion et l’expérimentation en vue que chacun participe à son amélioration. Une API ne se construit pas seul, elle est le fruit d’une collaboration afin que l’API puisse embrasser toutes les complexités du développement à son usage, en passant par son coût.

Bien évidemment, une fois ce prototype d’API construit, ce premier “most viable product” si cher à la méthode « lean », l’API pourrait être confiée à de vrais développeurs pour que celle-ci soit développée à nouveau à l’aide d’un framework plus “balaise” comme Symfony, Laravel ou Kohana.

Il existe pas mal de ressources pour concevoir une API de production et non un seul prototype comme c’est le cas dans ce billet. On donne dans cette article que les premières bonnes pratiques “Restfull” pour concevoir une API “restish” !

1. Guidelines & bonnes pratiques de construction d’une API

1.1 Les méthodes HTTP (HTTP Methods)

Toute bonne API se doit supporter les méthodes HTTP les plus couramment utilisés (GET, POST, PUT et DELETE)*. Certes, il existes d’autres méthodes tel que OPTIONS ou HEAD mais notre API va se concentrer sur les plus couramment utilisés. Chaque méthode sera utilisée en fonction du type d’opération qui sera mené.

[table type=”standard_bordered”]
[trow]
[thcol]METHODE[/thcol]
[thcol]DESCRIPTION[/thcol]
[/trow]
[trow] [tcol]GET[/tcol]
[tcol]Obtenir une ressource existante[/tcol]
[/trow]
[trow]
[tcol]POST[/tcol]
[tcol]Créer une nouvelle ressource[/tcol]
[/trow]
[trow]
[tcol]PUT[/tcol]
[tcol]Mettre à jour une ressource existante[/tcol]
[/trow]
[trow]
[tcol]DELETE[/tcol]
[tcol]Supprimer une ressource existante[/tcol]
[/trow]
[/table]

*Ces différentes opérations sont aussi connus sous l’acronyme CRUD (Create, Retrieve, Use, Delete)

1.2 HTTP Status Code ou connaitre les codes

[table type=”standard_bordered”]
[trow]
[thcol]STATUT[/thcol]
[thcol]DESCRIPTION[/thcol]
[/trow]
[trow]
[tcol]200[/tcol]
[tcol]OK[/tcol]
[/trow]
[trow]
[tcol]201[/tcol]
[tcol]Created[/tcol]
[/trow]
[trow]
[tcol]304[/tcol]
[tcol]Not Modified[/tcol]
[/trow]
[trow]
[tcol]400[/tcol]
[tcol]Bad Request[/tcol]
[/trow]
[trow]
[tcol]401[/tcol]
[tcol]Unauthorized[/tcol]
[/trow]
[trow]
[tcol]403[/tcol]
[tcol]Forbidden[/tcol]
[/trow]
[trow]
[tcol]404[/tcol]
[tcol]Not Found[/tcol]
[/trow]
[trow]
[tcol]422[/tcol]
[tcol]Unprocessable Entity[/tcol]
[/trow]
[trow]
[tcol]500[/tcol]
[tcol]Internal Server Error[/tcol]
[/trow]
[/table]

1.3 URL Structure, une structure d’URL explicite

Dans la conception d’une API REST, les extrémités des URL (endpoints) doivent être explicites et faciles à comprendre.

L’URL d’accès à chaque ressource doit être trivial et être identifié de manière unique.

Si l’API nécessite une clé afin d’accéder aux ressources, cette clé doit être stockée dans les headers HTTP et non dans l’URL.

Exemples :

• GET http://api.mondomaine.com/v1/projects/id/16 – Donne tous les détails du projet dont l’ID est 16.
• POST http://api.smondomaine.com/v1/projects/new – Créer un nouveau projet

1.4 API Versioning ou l’épineuse question de la version

Il existe un débat sans fin sur où indiquer la version de l’application dans l’URL ou les en-têtes HTTP. Même si la recommandation qui prévaut est de faire figurer la version dans l’en-tête, on choisit à la manière de Twitter, de faire figurer la version dans l’URL, cela indique plus facilement à l’utilisateur la version sur laquelle et se révèle bien plus commode lors d’une migration.

Après tout, une API est là pour exposer l’intelligence et le contenu de votre application aux utilisateurs alors autant faciliter la dialogue et la compréhension.

Exemples :

• http://api.mondomaine.com/v1.0/projects – version 1.0
• http://api.mondomaine.com/v1.2/projects – version 1.2
• http://api.mondomaine.com/v2.0/projects – version 2.0

1.5 Content Type, quel type de contenu

Les principaux format ou type de contenu que supporte habituellement les API Rest sont :

• Le JSON ex Mime Content-Type: application/json
• Le XML ex Content-Type: application/xml

Il existe bien sur d’autre formats ou type de contenu

Source : http://en.wikipedia.org/wiki/MIME_type

1.6 API Key, la clé du bonheur

En effet, exploiter une API coûte des ressources et c’est aussi un des socles de la monétisation d’un SaaS, il faut donc prévoir de réduire ou de limiter l’accès à cette ressource via une clé d’API.

C’est une évolution importante concernant la gestion d’une API. En effet si l’on pense monétisation, il faudra de facto faire évoluer le compte utilisateur à l’instar d’un Facebook ou Twitter. Dans un monde parfait, l’utilisateur gère lui-même ses apps, il déclare son/ses application(s), mets une description, obtient une clé d’API, un token client privé… bref toutes les informations nécessaires à la gestion d’une application adossée à une API. Tout cela est délégué à l’utilisateur, c’est le cercle vertueux pour une API, vous déléguer la gestion client à vos utilisateurs ainsi que tout ce qui concerne le paramétrage.

2. Créer une REST API _ User stories

2.1 Lâcher le silex pour le slim

Cretes, notre choix aurait ou se porter sur Silex qui est une émanation “light” de Symfony mais bon, le choix s’est porté sur Slim. En effet, quelques-unes des ressources (tutorial, vidéo notamment…) cadraient parfaitement avec le volonté affichée de cette expérience d’apprentissage : choisir un de ces micro framework PHP facile à mettre en place et à manœuvrer.

En conclusion, on aurait pu choisir Silex mais les recherches sur internet ont permis de découvrir une suite de 10 vidéos qui expliquent pas à pas l’utilisation de Slim.

1. Les videos d’Eduardo Diaz sur la maniement de Slim (spanish)
   http://www.youtube.com/user/alexdx/videos

2.2 Agile ?

Afin de se figurer comment concevoir l’API, le mieux est de décrire via des user stories ou des histoires utilisateurs l’usage que nous souhaitons faire de notre API.

(i) Simple User story ou actions habituelles

Bon les opération dites communes…

• Toutes les opérations relatives à l’inscription (registration) et de login
• Toutes les opérations liées à la gestion de projets (CRUD, Creating, Reading, Updating, Deleting). Pour toutes ces opérations, les appels à l’API doivent inclure une clé d’API d’autorisation dans le champ HEAD.

(ii) Advanced User story ou actions spécifiques

Les opérations plus avancées

• Lister tous les projets d’un compte utilisateur soit comme créateur (case 1) soit comme contributeur (case 2) soit les 2 (case 3).
• Lister tous les contributeurs à un projet donné
• Lister tous les mots-clés d’un projet donné.

…to be continued

Pour information, les principaux types de Requests sur une API REST : GET,POST, PUT, PATCH, DELETE, HEAD, OPTIONS.

3.3 Nomenclature des URLs : deux écoles

(i) Type 1 : Les URLs sont identiques mais les méthodes d’appel à l’API différent.

On peut souvent utiliser la même URL pour l’appel à l’API. Si l’URL est identique la différence se fait surtout sur le type de méthode HTTP qui est utilisé dans l’une ou l’autre des URLs.

Imaginons que le client demande l’URL de l’API /projects/id/:id d’un projet spécifique avec la méthode GET, le client obtiendra la liste des informations affairantes à ce projet. Si par contre le client utilise la méthode PUT

• /projects/id/:id GET -> Liste les infos d’un projet ayant cet id
• /projects/id/:id PUT -> Met à jour le projet ayant cet id
• /projects/id/:id DELETE -> Supprime le projet ayant cet id

(ii) Type 2 : Les URLs sont explicites et donnent un indication même sur la méthode employé.

Les URLs d’appel figurent autant que possible l’usage qui est fait. Personnellement c’est ce que je préfère, sortir de ce qui est implicite pour avoir de l’explicite. En effet, l’API peut-être testée et/ou utilisée par des personnes qui ignorent tous des conventions “techniques” et une simple lecture de la documentation de l’API suffit à convaincre que des nombreuses opérations sont possibles.

• /projects/id/:id GET -> Liste les infos d’un projet ayant cet id
• /projects/update/:id PUT -> Met à jour le projet ayant cet id
• /projects/delete/:id DELETE -> Supprime le projet ayant cet id

(iii) Tableau des structures Url de l’API + méthode

On a appliqué la nomenclature de Type 2. Pour mémoire, on décompose à nouveau une URL complète d’appel http://api.mondomaine.com/v2.0/projects/all.

• url_part_1 : http://api.mondomaine.com -> C’est l’URL de base, simple et facile à retenir.
• url_part_2 : /v2.0 -> C’est la partie qui indique la version de l’API à laquelle on fait l’appel.
• url_part_3 : /projects/all -> C’est la partie d’interaction avec l’API dans l’URL d’appel.

Ce qui donne le tableau suivant pour les combinaisons de la part_3

(A) User management

[table type=”standard_bordered”]

[trow]
[thcol]URL[/thcol]
[thcol]Method[/thcol]
[thcol]Parameters[/thcol]
[thcol]Description[/thcol]
[/trow]

[trow]
[tcol]/register[/tcol]
[tcol]POST[/tcol]
[tcol]mail, password[/tcol]
[tcol]User registration[/tcol]
[/trow]

[trow]
[tcol]/login[/tcol]
[tcol]POST[/tcol]
[tcol]mail, password[/tcol]
[tcol]User login[/tcol]
[/trow]
[/table]

(B) Project management
[table type=”standard_bordered”]

[trow]
[tcol]/projects/all[/tcol]
[tcol]GET[/tcol]
[tcol][/tcol]
[tcol]Fetching all projects[/tcol]
[/trow]

[trow]
[tcol]/projects/new[/tcol]
[tcol]POST[/tcol]
[tcol]project[/tcol]
[tcol]To create new project[/tcol]
[/trow]

[trow]
[tcol]/projects/id/:id[/tcol]
[tcol]GET[/tcol]
[tcol][/tcol]
[tcol]Fetching single project[/tcol]
[/trow]

[trow]
[tcol]/projects/update/:id[/tcol]
[tcol]PUT[/tcol]
[tcol][/tcol]
[tcol]Updating single project[/tcol]
[/trow]

[trow]
[tcol]/projects/delete/:id[/tcol]
[tcol]DELETE[/tcol]
[tcol]project, status[/tcol]
[tcol]Deleting single project[/tcol]
[/trow]
[/table]

(C) Tag management

[table type=”standard_bordered”]
[trow]
[tcol]/tags/all[/tcol]
[tcol]GET[/tcol]
[tcol][/tcol]
[tcol]Fetching all tags[/tcol]
[/trow]

[trow]
[tcol]/tags/new[/tcol]
[tcol]POST[/tcol]
[tcol]tag[/tcol]
[tcol]To create new tag or hashtag[/tcol]
[/trow]

[trow]
[tcol]/tags/id/:id[/tcol]
[tcol]GET[/tcol]
[tcol][/tcol]
[tcol]Fetching single tag[/tcol]
[/trow]

[trow]
[tcol]/tags/update/:id[/tcol]
[tcol]PUT[/tcol]
[tcol][/tcol]
[tcol]Updating single tag[/tcol]
[/trow]

[trow]
[tcol]/tags/delete/:id[/tcol]
[tcol]DELETE[/tcol]
[tcol]tag, status[/tcol]
[tcol]Deleting single tag[/tcol]
[/trow]

[/table]

(D) Author management

[table type=”standard_bordered”]

[trow]
[tcol]/authors/all[/tcol]
[tcol]GET[/tcol]
[tcol][/tcol]
[tcol]Fetching all authors[/tcol]
[/trow]

[trow]
[tcol]/authors/new[/tcol]
[tcol]POST[/tcol]
[tcol]author[/tcol]
[tcol]To create new author[/tcol]
[/trow]

[trow]
[tcol]/authors/id/:id[/tcol]
[tcol]GET[/tcol]
[tcol][/tcol]
[tcol]Fetching single author[/tcol]
[/trow]

[trow]
[tcol]/authors/update/:id[/tcol]
[tcol]PUT[/tcol]
[tcol][/tcol]
[tcol]Updating single author[/tcol]
[/trow]

[trow]
[tcol]/authors/delete/:id[/tcol]
[tcol]DELETE[/tcol]
[tcol]author, status[/tcol]
[tcol]Deleting single author[/tcol]
[/trow]
[/table]

(E) Downloads management

[table type=”standard_bordered”]
[trow]
[tcol]/downloads/all[/tcol]
[tcol]GET[/tcol]
[tcol][/tcol]
[tcol]Fetching all downloads[/tcol]
[/trow]

[trow]
[tcol]/downloads/id/:id[/tcol]
[tcol]GET[/tcol]
[tcol][/tcol]
[tcol]Fetching nb of downloads for a single project[/tcol]

[/trow]

[/table]

((F) Goodies management

Quelques actions juste pour le fun maintenant, il faut voir si elles ne sont pas consommatrices de resources.

[table type=”standard_bordered”]

[trow]

[tcol]/projects/all/top/day[/tcol]
[tcol]GET[/tcol]
[tcol]Transverse, Sur une journée, les derniers projets mis à jour du plus récent au plus ancien[/tcol]
[/trow]

[trow]
[tcol]/projects/all/top/week[/tcol]
[tcol]GET[/tcol]
[tcol]Idem sur une semaine[/tcol]
[/trow]

[trow]
[tcol]/projects/all/top/month[/tcol]
[tcol]GET [/tcol]
[tcol]Idem sur un mois[/tcol]
[/trow]

[trow]
[tcol]/projects/all/top/year [/tcol]
[tcol]GET [/tcol]
[tcol]Idem sur une année[/tcol]
[/trow]

[trow]
[tcol]/projects/all/top/alltime[/tcol]
[tcol]GET [/tcol]
[tcol]Idem depuis que le service existe[/tcol]
[/trow]

[trow]
[tcol]/projects/id/:id/authors/all/top/month[/tcol]
[tcol]GET[/tcol]
[tcol]Par projet, les auteurs les plus actifs du mois sur le projet dont l’id est :id[/tcol]
[/trow]

[trow]
[tcol]/authors/all/top/month[/tcol]
[tcol]GET[/tcol]
[tcol]Transverse, les auteurs les plus actifs du mois tous projets confondues[/tcol]
[/trow]

[/table]

L’idée est sans doute de comprendre le fonctionnement et de s’amuser à faire toutes les combinaisons, ensuite voir si cela fait sens et si c’est techniquement faisable notamment pas chargeant en terme de requête ! Cache ?

3. Créer une REST API _ Ride the ORM

Pour la construction de l’API, il faut d’évidence s’appuyer sur l’ORM d’un framework.

Prenons par exemple par Kohana, il existe quelques exemples dans Kohana sur l’utilisation de l’ORM, voir /kohana/modules/orm/guide/orm/examples/ notamment le fichier simple.md

3.1 Notes sur l’ORM de Kohana

The ORM allows for manipulation and control of data within a database as though it was a PHP object. Once you define the relationships ORM allows you to pull data from your database, manipulate the data in any way you like, and then save the result back to the database without the use of SQL. By creating relationships between models that follow convention over configuration, much of the repetition of writing queries to create, read, update, and delete information from the database can be reduced or entirely removed. All of the relationships can be handled automatically by the ORM library and you can access related data as standard object properties.

ORM is included with the Kohana 3.x install but needs to be enabled before you can use it. In your `application/bootstrap.php` file modify the call to Kohana::modules and include the ORM modules.

Bon dans notre exemple, on va utiliser RedBeanPHP accessible sans trop de souci via Slim

4. Créer une REST API _ Installer Slim

On va installer à l’aide de composer un ensemble d’éléments nécessaires au bon fonctionnement de notre application. On a renoncé à Laravel et son ORM Eloquent.

Les commandes pour se rendre dans votre répertoire puis installer le tout.

cd /Applications/MAMP/htdocs/slim/slim_test_api/
composer install
Le contenu de composer.json avec slim et RedBeanPHP

	{
	    "require": {
	        "slim/slim": "2.*",
			"gabordemooij/redbean": "*"
 
	    }
	}

Lancer le composer composer install

C’est fait, vous avez slim et redbean dans un répertoire vendor

Confirmation ls -l

Confirmation ls -la pour voir le .htaccess

Le code de .htaccess

	RewriteEngine On
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteRule ^ index.php [QSA,L]

5. Utiliser notre API _ Quelques exemples…

Pour jouer avec notre prototype d’API, on va utiliser l’application de Chrome nommé “Advanced REST client” afin de passer quelques commandes, du même on indique aussi le moyen de passer la même commande à l’aide de cURL.

Dans Chrome, une application nommée “Advanced REST client”

Source : Advanced REST client de Google Chrome

5.1 Voir les utilisateurs de la BDD

En cURL

curl -i -X GET http://127.0.0.1/slim/slim_test_api_redbean/index.php/api/usuarios/all

curl -i -X GET http://127.0.0.1/slim/slim_test_api_redbean/index.php/api/usuarios/id/4

5.2 Ajouter des utilisateurs

http://127.0.0.1/slim/slim_test_api_redbean/index.php/api/usuarios/new

{"nombre": "Barack","apellidos":"Obama","email":"bo@whitehouse.gov"}
{"nombre": "Michelle","apellidos":"Obama","email":"mo@whitehouse.gov"}
{"nombre": "John","apellidos":"Smith","email":"mdoe@whitehouse.gov"}

curl -i -X POST -H 'Content-Type: application/json' -d '{"nombre": "Damian","apellidos":"Winograd","email":"dwg@whitehouse.gov"}' http://127.0.0.1/slim/slim_test_api_redbean/index.php/api/usuarios/new

Ajouter un utilisateur via Advanced REST client de Google Chrome

Bien ajouter application/json

Le message de notre api en espagnol

Ajouter un utilisateur en cURL

Vue utilisateur unique ID 4

Vue tous les utilisateurs

Vue tous les utilisateurs via cURL

5.3 Supprimer des utilisateurs

http://127.0.0.1/slim/slim_test_api_redbean/index.php/api/usuarios/delete/13

curl -i -X DELETE http://127.0.0.1/slim/slim_test_api_redbean/index.php/api/usuarios/delete/13

Supprimer un utilisateur via Advanced REST client de Google Chrome

Supprimer un utilisateur en cURL

Le dump .sql de la base via phpmyadmin

	-- phpMyAdmin SQL Dump
	-- version 4.2.5
	-- http://www.phpmyadmin.net
 
	SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
	SET time_zone = "+00:00";
 
	--
	-- Base de données :  `slim`
	--
 
	-- --------------------------------------------------------
 
	--
	-- Structure de la table `usuarios`
	--
 
	CREATE TABLE `usuarios` (
	`id` INT(9) NOT NULL,
	  `nombre` VARCHAR(50) NOT NULL DEFAULT '',
	  `apellidos` VARCHAR(100) NOT NULL DEFAULT '',
	  `email` VARCHAR(255) NOT NULL DEFAULT '',
	  `alta` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
	) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=14 ;
 
	--
	-- Contenu de la table `usuarios`
	--
 
	INSERT INTO `usuarios` (`id`, `nombre`, `apellidos`, `email`, `alta`) VALUES
	(4, 'Bob', 'Obama', 'bobobama@whitehouse.gouv', '2014-10-31 07:37:35'),
	(12, 'Damian', 'Winograd', 'dwg@whitehouse.gov', '2014-11-03 04:34:41'),
	(7, 'Ramon', 'Castro', 'ramonc@hotmail.com', '2014-10-31 08:23:43'),
	(9, 'Barack', 'Obama', 'bo@whitehouse.gov', '2014-11-03 04:15:22'),
	(10, 'Michelle', 'Obama', 'mo@whitehouse.gov', '2014-11-03 04:15:41');
 
	--
	-- Index pour les tables exportées
	--
 
	--
	-- Index pour la table `usuarios`
	--
	ALTER TABLE `usuarios`
	 ADD PRIMARY KEY (`id`);

6. Utiliser notre API _ le code

Le fichier index.php de notre prototype de API

	<?php
	/**
	 * Slim - a micro PHP 5 framework
	 *
	*/
 
			require 'vendor/autoload.php';
			use RedBean_Facade as R;
 
			$db_host = "localhost";
			$db_dbname = "slim";
			// $db_dbname = "all_traductions";
			$db_username = "root";
	        $db_password = "root";
 
 
			R::setup ('mysql:host='.$db_host.';dbname='.$db_dbname.';chartset=utf8',''.$db_username.'',''.$db_password.'');
 
			R::freeze(true);
 
			$app = new \Slim\Slim();
			$app->config(array(
			    'debug' => true
			));
 
			$app->get('/', function () use($app) {
				echo ('<h1>Hello to redbean ($app)</h1>');
			});
 
			/* ALL */
			// http://127.0.0.1/slim/slim_test_api_redbean/index.php/api/usuarios/all
			$app->group('/api', function () use ($app){
					$app->group('/usuarios', function () use ($app){
						$app->response->headers->set('Content-Type', 'application/json');
 
							$app->get('/all', function () use($app) {
								$all = R::find('usuarios');
								$all_users = R::exportAll($all);
								echo json_encode($all_users);
							});
							/* LOOK for an ID */
							// http://127.0.0.1/slim/slim_test_api_redbean/index.php/api/usuarios/id/1
							$app->get('/id/:id', function ($id) use($app) {
								try{
									//all infos about the user based on the id
									$usuario = R::load('usuarios', $id);
									if ($usuario->id) {
										$user = $usuario->export();
										echo json_encode($user);
									} else {
										throw new Exception('User does not exist');
									}
								}catch (Exception $e) {
									$app->status(400);
									echo json_encode(array('status' => 'error', 'message' => $e->getMessage()));
								}
							});
							/* NEW ID */
							// http://127.0.0.1/slim/slim_test_api_redbean/index.php/api/usuarios/new
							$app->post('/new', function () use($app) {
								try{
									$request = $app->request();
									$data = json_decode ($request->getBody());
									$usuario = R::dispense('usuarios');
									$usuario->nombre = $data->nombre;
									$usuario->apellidos = $data->apellidos;
									$usuario->email = $data->email;
									$insertado = R::store($usuario);
									if ($insertado) {
											echo json_encode(array('status' => 'success', 'message' => 'Insertado correctamente'));
									} else {
										throw new Exception('Error while inserting the user');
									}
								}catch (Exception $e) {
									$app->status(400);
									echo json_encode(array('status' => 'error', 'message' => $e->getMessage()));
								}
							});
 
							/* UPDATE */
							// http://127.0.0.1/slim/slim_test_api_redbean/index.php/api/usuarios/update/2
							$app->put('/update/:id', function ($id) use($app) {
								try{
									$id = (int)$id;
									$request = $app->request();
									$data = json_decode ($request->getBody());
									$usuario = R::load('usuarios', $id);
									if ($usuario->id) {
										//Actulizamos datos del usuario
										$usuario->nombre = $data->nombre;
										$usuario->apellidos = $data->apellidos;
										$usuario->email = $data->email;	
										R::store($usuario);
										echo json_encode(array('status' => 'success', 'message' => 'Actualizado correctamente'));
									} else {
										throw new Exception('Error while updating the user');
									}
								}catch (Exception $e) {
									$app->status(400);
									echo json_encode(array('status' => 'error', 'message' => $e->getMessage()));
								}
							});
							/* DELETE */
							// http://127.0.0.1/slim/slim_test_api_redbean/index.php/api/usuarios/delete/8
							$app->delete('/delete/:id', function ($id) use($app) {
								$id = (int)$id;
								try{
									// Buscamos y borramos
	 								$usuario = R::load('usuarios', $id);
									if ($usuario->id) {
										R::trash($usuario);
										echo json_encode(array('status' => 'success', 'message' => 'Borrado correctamente'));
									} else {
										throw new Exception('Error while deleting the user');
									}
								}catch (Exception $e) {
									$app->status(400);
									echo json_encode(array('status' => 'error', 'message' => $e->getMessage()));
								}
 
							});
 
					});
				});
 
			$app->run();

En savoir plus

• Les videos d’Eduardo Diaz sur la maniement de Slim (spanish)
  http://www.youtube.com/user/alexdx/videos
• Learn REST: A RESTful Tutorial
  http://www.restapitutorial.com/
• Un excellent framework PHP, Laravel notamment avec son ORM Eloquent
  http://laravel.com/
• L’ORM utilisé dans notre demo, RedBeanPHP is an easy-to-use, on-the-fly ORM for PHP
  http://redbeanphp.com/
• L’auteur de Build APIs You Won’t Hate et un très fin connaisseur de Laravel et des bonnes pratiques
  https://philsturgeon.uk/
• Un assortiment d’excellentes vidéos sur SLIM(espagnol)
  http://12devsofxmas.co.uk/2012/12/day-4-mixing-and-matching-php-components-with-composer/
• How to create REST API for Android app using PHP, Slim and MySQL – Day 1/2
  http://www.androidhive.info/2014/01/how-to-create-rest-api-for-android-app-using-php-slim-and-mysql-day-12-2/
• How to create REST API for Android app using PHP, Slim and MySQL – Day 2/2
  http://www.androidhive.info/2014/01/how-to-create-rest-api-for-android-app-using-php-slim-and-mysql-day-23/
• Creating a RESTful API with PHP using Slim
  http://www.aljtmedia.com/blog/creating-a-restful-api-with-php-using-slim/
• Create REST applications with the Slim micro-framework
  http://www.ibm.com/developerworks/library/x-slim-rest/
• Creating a simple REST application with Silex de DAVID MAKIN (part 1)
  http://sleep-er.co.uk/blog/2013/Creating-a-simple-REST-application-with-Silex/
• Creating a simple REST application with Silex de DAVID MAKIN (part 2)
  http://sleep-er.co.uk/blog/2014/Creating-a-simple-REST-application-with-Silex-part2/
• Learning PHP development with Silex de Bojan Živanović
  http://bojanz.wordpress.com/2013/11/11/learning-php-development-with-silex/
• MusicBox is a portal based on the Silex framework, built for PHP 5.3 and MySQL 5. It tries to demonstrate best practices in today’s world of development, and has been written as a university project by Bojan Zivanovic and Lana Petkovic.
  https://github.com/bojanz/musicbox
• The PHP micro-framework
  based on the Symfony2 Components
  hhttp://silex.sensiolabs.org/documentation
• Scaling a Silex code base
  https://igor.io/2012/11/09/scaling-silex.html
• A First Silex Project
  http://sf.khepin.com/2011/04/a-first-silex-project/
• Building APIs with Silex by Cal Evans of Blue Parabola
  http://www.youtube.com/watch?v=bqxxI_pwcXA