{"id":10436,"date":"2014-11-06T00:43:11","date_gmt":"2014-11-05T23:43:11","guid":{"rendered":"http:\/\/flaven.fr\/?p=10436"},"modified":"2026-05-12T19:03:52","modified_gmt":"2026-05-12T17:03:52","slug":"slim-api-framework-les-bonnes-pratiques-pour-creer-une-api-avec-le-micro-framework-php-slim","status":"publish","type":"post","link":"https:\/\/flaven.fr\/2014\/11\/slim-api-framework-les-bonnes-pratiques-pour-creer-une-api-avec-le-micro-framework-php-slim\/","title":{"rendered":"Slim, API, Framework – Les bonnes pratiques pour cr\u00e9er une API avec le micro-framework PHP Slim"},"content":{"rendered":"


\n \t<\/p>\n

Il s’agit de comprendre rapidement comment concevoir puis de coder “grosses mailles” une API.<\/p>\n

Les objectifs de cette exp\u00e9rience \u00e9taient les suivants : <\/p>\n

    \n
  1. D\u00e9couvrir les principes et les meilleures pratiques possibles pour concevoir une API.<\/li>\n
  2. Choisir un micro framework ou petit framework pour r\u00e9aliser ce prototype d’API afin d’avoir un exemple fonctionnel au bout d’une seule it\u00e9ration.<\/li>\n
  3. Appliquer \u00e0 la lettre un principe de la m\u00e9thode “lean” : lancer au plus vite une r\u00e9alisation m\u00eame imparfaite dont la fonction premi\u00e8re est de servir de base \u00e0 la discussion et l’exp\u00e9rimentation en vue que chacun participe \u00e0 son am\u00e9lioration. Une API ne se construit pas seul, elle est le fruit d’une collaboration afin que l’API puisse embrasser toutes les complexit\u00e9s du d\u00e9veloppement \u00e0 son usage, en passant par son co\u00fbt.<\/li>\n<\/ol>\n

    Bien \u00e9videmment, une fois ce prototype d’API construit, ce premier “most viable product” si cher \u00e0 la m\u00e9thode \u00ab\u00a0lean\u00a0\u00bb, l’API pourrait \u00eatre confi\u00e9e \u00e0 de vrais d\u00e9veloppeurs pour que celle-ci soit d\u00e9velopp\u00e9e \u00e0 nouveau \u00e0 l’aide d’un framework plus “balaise” comme Symfony, Laravel ou Kohana.<\/p>\n

    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\u00e8res bonnes pratiques “Restfull” pour concevoir une API “restish” !<\/b>
    \n<\/p>\n

    1. Guidelines & bonnes pratiques de construction d’une API<\/h2>\n

    1.1 Les m\u00e9thodes HTTP (HTTP Methods)<\/h4>\n

    Toute bonne API se doit supporter les m\u00e9thodes HTTP les plus couramment utilis\u00e9s (GET, POST, PUT et DELETE)*. Certes, il existes d’autres m\u00e9thodes tel que OPTIONS ou HEAD mais notre API va se concentrer sur les plus couramment utilis\u00e9s. Chaque m\u00e9thode sera utilis\u00e9e en fonction du type d’op\u00e9ration qui sera men\u00e9.<\/p>\n

    [table type=”standard_bordered”]
    \n[trow]
    \n\t\t[thcol]METHODE[\/thcol]
    \n\t\t[thcol]DESCRIPTION[\/thcol]
    \n[\/trow]
    \n[trow]\t[tcol]GET[\/tcol]
    \n\t\t[tcol]Obtenir une ressource existante[\/tcol]
    \n[\/trow]
    \n[trow]
    \n\t\t[tcol]POST[\/tcol]
    \n\t\t[tcol]Cr\u00e9er une nouvelle ressource[\/tcol]
    \n[\/trow]
    \n[trow]
    \n\t\t[tcol]PUT[\/tcol]
    \n\t\t[tcol]Mettre \u00e0 jour une ressource existante[\/tcol]
    \n[\/trow]
    \n[trow]
    \n\t\t[tcol]DELETE[\/tcol]
    \n\t\t[tcol]Supprimer une ressource existante[\/tcol]
    \n[\/trow]
    \n[\/table]<\/p>\n

    *Ces diff\u00e9rentes op\u00e9rations sont aussi connus sous l’acronyme CRUD (Create, Retrieve, Use, Delete)<\/i>
    \n<\/p>\n

    1.2 HTTP Status Code ou connaitre les codes<\/H4>
    \nLes diff\u00e9rents statuts de codes HTTP permettent d’informer quelle action doit \u00eatre accomplie par l’application cliente. Fournir au plus vite un statut est du point de l’utilisation des serveurs, beaucoup plus efficient donc forc\u00e9ment \u00e9conomique en effet la r\u00e9ponse est imm\u00e9diate, on indique donc au client (app, browser…) de ne pas chercher plus loin.
    \n<\/p>\n

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

    1.3 URL Structure, une structure d’URL explicite<\/h4>\n

    Dans la conception d’une API REST, les extr\u00e9mit\u00e9s des URL (endpoints) doivent \u00eatre explicites et faciles \u00e0 comprendre.<\/p>\n

    L’URL d’acc\u00e8s \u00e0 chaque ressource doit \u00eatre trivial et \u00eatre identifi\u00e9 de mani\u00e8re unique.<\/p>\n

    Si l’API n\u00e9cessite une cl\u00e9 afin d’acc\u00e9der aux ressources, cette cl\u00e9 doit \u00eatre stock\u00e9e dans les headers HTTP et non dans l’URL.<\/p>\n

    Exemples :<\/b><\/p>\n