Sk's Memory

Réalisé par Kouame Samuel Etudiant en science informatique
Ministère de la Communication de l’Economie Numérique

Et de la poste, Porte-parole du Gouvernement.
Gouvernement.
Institut des technologies et des spécialités
Année académique : 2021 / 2022
MEMOIRE DE FIN DE CYCLE POUR L’OBTENTION DE LA

LICENCE EN SYSTEMES INFORMATIQUES
DEVELOPPEMENT D’UN API REST EN

PHP
QUELLE EST L’IMPORTANCE DE L’ARCHITECTURE REST DANS LE DEVELOPPEMENT DES SERVICES WEB ?
Présenté par :
KOUAME SAMUEL EBENEZER
Réalisé par Kouame Samuel Ebenezer, Etudiant en système Informatique
Encadrant académique :
MR EDDI
DEDICACE
A mon Père et ma Mère:

Que cet ouvrage soit la récompense de tout son sacrifice et le témoignage de
toute ma gratitude et de mon entière affection.
A mes frères et sœurs :
Pour leurs soutiens tant que financier, affectifs et moraux.
A tout mes amis de la licence 3 ITES :
En souvenir de toutes les années passées ensemble.
REMERCIEMENTS
Le présent mémoire a pu être mené à terme grâce à l’implication de plusieurs personnes pour
lesquelles je ferais part d’ingratitude et de mauvaise foi si celles-ci ne faisaient pas l’objet de
remerciements. Ainsi donc j’aimerais remercier :
 Monsieur EDDI MOUSSO, Professeur et directeur d’ITES 2PLATEAUX qui a bien voulu donner son
accord pour la concrétisation de ce travail ;
 Monsieur DJEGRE, d’ITES 2PLATEAUX.
 KODJO ISAAC, développeur fullstack chez Big Five Solutions pour avoir accepté d’affecter un temps
à ce modeste travail et de l’attribuer des remarques et des corrections.
 Le Corps Enseignant et le Personnel Administratif de l’Institut des technologies et spécialités(ITES),

les personnels administratifs et techniques.
 Des remerciements à l’endroit de mes ami(e)s proches notamment MANLAN A. NATHAN, KONE
A. ROMARIC pour le soutien et l’aide apportés.
 Mes remerciements vont également à l’endroit de mes ami(e)s de la LICENCE 3 2021-2022 d’ITES
2PLATEAUX et en particulier à N’GUESSAN C.MATTHIEU, TAPE ISRAEL, KOFFI DAVID
pour leur soutien et leurs conseils, apportés durant tout mon parcours.
LISTE DES FIGURES
Figure 1 : Répartition des protocoles utilisés par les API.…………12
Figure 2 : Illustration d’une Architecture Rest……………………14
Figure 3 : Illustration du modèle de maturité de Richardson……21
Figure 4: Structure d’une API REST…………………………………..31
LISTE DES TABLEAUX
Tableau 1: Abréviation…………………………………………………………………………8
Tableau 2: Liste des principales méthodes……………………………………………25
Tableau 3: Exemples de codes de retour par Action en fonction du résultat….29

Tableau 4 : Détails de l’API REST…………………………………………………………………………31
TABLE DE MATIERE
Dédicace………………………………………………………………………………………..4
Remerciement………………………………………………………………………………..5
Liste des tableaux et figures……………………………………………………………6
1. Glossaire …………………………………………………………………………………….8
2. Introduction………………………………………………………………………………..10
2.1. Web service…………………………………………………………………………..10
2.2. Etat des lieux…………………………………………………………………………11
2.3. Objectif de ce mémoire……………………………………………………………12
3. Les bases de REST…………………………………………………………………………13
3.1. Qu’est-ce que REST…………………………………………………………………13
3.2. Les principes clé du REST…………………………………………………………17
3.3. Le modèle de maturité de Richardson………………………………………20
3.4. Les méthodes http en REST………………………………………………………25
4. Conception d’une API REST……………………………………………………………30
5. Conclusion ……………………………………………………………………………………43
Bibliographie et webographie……………………………………………………………45
1.GLOSSAIRE
La liste ci-dessous contient toutes les abréviations utilisées dans ce document.
Tableau 1 : Abréviations
Abréviation Signification
API Application Programming Interface
C# C sharp (langage de programmation orienté objet)
CRUD Create Read Update Delete
DCE/RPC Remote Procedure Calls
HATEOAS Hypermedia As The Engine Of Application State

Hypertext Markup Language

HTML
Java Langage de programmation orienté objet
JSON JavaScript Object Notation
REST Representational State Transfer
SMTP Simple Mail Transfer Protocol
SOAP Simple Object Access Protocol
URI Uniform Resource Identifier
URL Uniform Resource Locator
XML Extensible Markup Language
JAVASCRIPT Langage de programmation orienté objet
PHP/RUBY Langage de programmation orienté objet

2. INTRODUCTION
Aujourd’hui, une majorité de services Web populaires qui proposent une API (Application Program Interfact)
le font en utilisant le style d’architecture REST
(Representational State Transfer). Ce mémoire est consacré à la mise en place d’un Web Service REST. Il
se subdivise en deux parties, dans la première partie nous allons définir ce que c’est l’architecture REST et
en deuxième partie comment concevoir une API REST
Comme nous le verrons de ce mémoire, il existe différents points de vue sur la théorie de REST. Ce
mémoire s’attachera donc à étudier la problématique suivante : quelle est l’importance de l’architecture
REST dans le développement des Services Web?
Pour tenter de répondre à cette problématique, dans un premier temps, nous nous attacherons à identifier
les grands principes de REST. Dans un second temps, nous mettrons ces grands principes avec un cas de
développement d'une application PHP de gestion de produits implémentant un Web Service REST. Les
aspects techniques, les concepts de programmation et de conception de l'application seront expliqués.
1. Les Web Services
Faisant partie de la famille des technologies Web, un service Web permet à des applications et des
systèmes divers de communiquer et d’échanger des données dans des environnements partagés. Cette
technologie permet donc à des applications distantes de communiquer à travers un réseau (Internet) sans
tenir compte des différences de langages de programmation et de plates-formes. Dans ce cadre, via un
service Web, une application « A » codée en « Java » peut communiquer avec une application « B » codée
en « C# ». Les requêtes et les réponses s’effectuent à l’aide de formats ouverts tels que :
• XML
• JSON
Il existe aujourd’hui deux styles architecturaux pour concevoir un Web Service : les services REST et les
services SOAP (Simple Object Access Protocol).
SOAP
SOAP (Simple Object Access Protocol) est un protocole créé par Microsoft permettant d’invoquer des
méthodes sur des services distants. Il est basé sur le langage XML. Le transfert d’informations peut se faire
en HTTP mais également par un autre protocole, comme SMTP par exemple.
REST
REST n’est pas une technologie ni un protocole comme peut l’être SOAP. C’est plutôt une philosophie
d’utilisation du Web. Il utilise le protocole HTTP et estime que celui-ci, couplé avec de bonnes URI, est
suffisant pour créer un Web Service dans la majorité des cas.
REST est aujourd’hui souvent préféré à SOAP car il est plus léger et plus simple à mettre en place. Une
autre raison est également le fait que SOAP soit défini pour retourner du XML.
Pour des applications en JavaScript, Ruby ou PHP, le format JSON est généralement préféré au XML car
plus simple à manipuler.
2. État des lieux de la situation

Selon postman.com, jusqu’à aujourd’hui REST reste de loin l’architecture API la plus utilisée.
Les pourcentages sur le graphique ci-dessous sont tout de même à nuancer. En effet, ils représentent
les pourcentages des API qui sont listées sur postman.com. Ces pourcentages ne correspondent donc
pas à la totalité des API du Web.
Figure 1 : Répartition des protocoles utilisés par les API

Source: 2022 State of the API Report | API Technologies (postman.com)
3. Objectifs de ce mémoire
Ce mémoire a pour objectif de montrer l’importance de L’Architecture REST dans le développement des
Web services REST.
Nous allons ainsi avancer autour de 3 points majeurs :
● comprendre les principes fondamentaux de REST

● savoir mesurer la conformité d’une API REST
● montrer comment développer une API REST
2. LES BASES DE REST
2.1 Qu’est-ce que REST
DEFINITION
REST n’est pas un protocole, c’est un style d’architecture utilisé pour la conception de services Web. Il a été
introduit en 2000 par Roy Fiedling dans sa thèse de doctorat. Cette méthodologie est une alternative au
protocole SOAP. REST fournit un ensemble de contraintes architecturales qui permettent d’accéder et de
manipuler les données. L’adjectif anglais « RESTful » qualifie les systèmes qui respectent les contraintes
architecturales de REST. Utilisé par les colosses de l’informatique (Google, Amazon, …), REST se base
uniquement sur le protocole HTTP pour la communication client-serveur.
Succinctement, une API REST est une application qui expose des ressources via les URL avec lesquelles il
est possible d’interagir. REST s’appuie sur le protocole HTTP pour décrire les actions à réaliser sur les
ressources : GET, POST, PUT et DELETE pour récupérer, créer, modifier ou supprimer une ressource
REST repose sur les standards du web : protocole HTTP, URL, format des fichiers pour utiliser les
ressources (XML, HTML, JPEG, etc.). Pour REST, le protocole HTTP suffit largement à l’ensemble de
besoins d’un Service Web, pour peu que nous utilisions l’ensemble de ces méthodes (GET, PUT, POST,
DELETE, etc.).
Figure 2 : Illustration d’une Architecture Rest
Source : https://blog.nicolashachet.com/
Roy Fielding définit (dans le chapitre 5 de sa thèse) les contraintes REST. Selon sa définition, REST est une
architecture construite avec les contraintes suivantes :
● Interface Uniforme
● Sans état
● Client-Serveur
● Système hiérarchisé par couches
● Code à la demande
Pour d’autres auteurs, comme Pautasso, Zimmermann and Leymann, REST repose sur quatre contraintes
différentes (Addressabilité, Interface Uniforme, HATEOAS et Sans état).
En résumé, REST propose des contraintes architecturales qui permettent à un client et un serveur
d’échanger des données par le biais du protocole HTTP. REST n’est pas un protocole ni une technologie à
part entière, il s’agit d’un ensemble de principes et bonnes pratiques. Cela souligne le fait que REST est une
architecture qui laisse place à l'interprétation. Comme déjà mentionné, il n'existe pas une architecture REST
définie. Les critères de conception dépendent donc du point de vue de l'auteur et de son interprétation.
AVANTAGES
Les avantages de REST par rapport à d’autres architectures d’applications Web sont les suivants :
● Les interfaces sont généralisées, c’est-à-dire que toutes les applications doivent implémenter leurs inter-
faces de la même manière. En partageant les mêmes conventions, il est facile de savoir comment utiliser
l’API. Cela réduit la courbe d’apprentissage pour chaque nouvelle application.
 Il suffit d'un navigateur pour accéder à un service.
 Mise en cache des ressources, donc accélération des opérations.
 Moins de consommation mémoire.
 Possibilité de répartir les requêtes sur plusieurs serveurs. Cela grâce à l'absence d'états.
 L'utilisation de formats standards comme HTML ou XML assure la compatibilité dans le temps.
 On peut échanger des requêtes entre diverses applications ou média car elles sont
représentées par des URI
 Le serveur ne gère pas l’état du client. Une session client n’appartient pas à un serveur en
particulier. Cela permet une meilleur scalabilité de l’application, en rendant plus simple l’ajout
d’autres serveurs par exemple.
 REST utilise des concepts déjà connus des développeurs Web : le protocole HTTP et les URI
pour accéder aux ressources.
LES CONCEPT UTILISES PAR REST
Avant de plonger dans les principes directeurs de la conception des API REST, discutons brièvement de
trois termes clés de l'API :
 LOGICIELS
Le client est un matériel ou un logiciel qui utilise l'API rendue accessible par un serveur. Par exemple,
lorsque vous visitez le site Web de Facebook, votre navigateur est le client qui appelle l'API de Facebook et
utilise les données renvoyées pour afficher des informations sur votre écran.
 RESSOURCE
Une ressource peut être n'importe quel objet sur lequel l'API peut offrir des informations.
Ainsi, un utilisateur, un bookmark, ou bien une facture peuvent être considérés comme des ressources.
La ressource est la principale abstraction d'informations dans REST. L'API REST utilise un identifiant de
ressource pour reconnaître la ressource spécifique impliquée dans la communication entre différents élé-
ments.
Une ressource peut être accessible par plusieurs URI. Pour autant, il est d’usage de définir au moins une
URI canonique qui sera alors l’URI de référence.
Par exemple : Recherche de la liste des livres
http://mywebsite.com/books
Si l’ID du livre rechercher est 87 alors les réponses seront identiques mais l’URI canonique est :
http://mywebsite.com/books/87
 REPRESENTATION
Selon Roy Fiedling, les représentations sont “un ensemble de données relatives à l’état courant d’une res-
source”. La représentation est donc simplement la forme dans laquelle le serveur va retourner les informa-
tions demandées
Il peut y avoir plusieurs types de représentations pour une seule et même ressource : un document XML ou
JSON, une page HTML, une image PNG, etc. On les appelle des formats.
Si l’on se place côté client, la nature d’une ressource n’est pas connue car le client n’indique que des URI et
des représentations. S’il cherche à créer une ressource sur le serveur, il ne transmettra que la représenta-
tion de ce qu’il souhaite. C’est le serveur qui va créer la ressource en utilisant tout ou partie de l’information
transmise par le client.
Exemples de représentations en XML et JSON d’un utilisateur :
1 {
2 "Id": 1,
3 "Name": "Nathan Malan",
4 "Email": "Nathanmalan12@gmail.com",
5 "Country": "Cote d’ivoire"
6 }
1 <user>
2 <id>42</id>
3 <name>Nathan Malan</name>
4 <email> Nathanmalan12@gmail.com</email>
5 <country>Cote D’ivoire</country>
</user>
2. Principes clés du REST
Nous avons évoqué un peu plus haut que l’API REST se base sur un ensemble de règles à respecter lors
de sa création et de ses appels. En réalité, il existe six principes qui permettent de déduire qu’une API est
RESTful : l’architecture client-serveur, sans état, cacheable, interface uniforme, système en couches, code
à la demande.
2.1Les concepts utilises par REST
 Interface Uniforme
Une API REST doit se soumettre à une architecture spécifique que le client et le serveur doivent absolu-
ment respecter. Cette uniformité permet de simplifier l’interaction entre les deux parties, améliore la visibilité
de celle-ci et renforce également leur autonomie.
Il y a quatre contraintes d’interface qu’il faut respecter dans l’élaboration d’une API REST : l’identification
des ressources, le traitement de celles-ci par des représentations, les interactions auto-descriptives et l’utili-
sation de l’hypermédia comme moteur de l’état de l’application.
 Basé sur les ressources : les ressources individuelles sont identifiées dans les requêtes (requests).
Par exemple : API/utilisateurs.
 Manipulation des ressources via des représentations : le client a une représentation de la ressource
et elle contient suffisamment d’informations pour modifier ou supprimer la ressource sur le serveur, à
condition qu’il ait l’autorisation de le faire. Exemple : Habituellement, l’utilisateur obtient un identifiant
d’utilisateur lorsqu’il demande une liste d’utilisateurs, puis utilise cet identifiant pour supprimer ou mo-
difier cet utilisateur particulier.
 Messages auto-descriptifs : chaque message comprend suffisamment d’informations pour décrire

comment traiter le message afin que le serveur puisse facilement analyser la demande.
 Hypermedia as the Engine of Application State (HATEOAS): Il doit inclure des liens pour chaque ré-
ponse afin que le client puisse découvrir facilement d’autres ressources.
 Stateless (Sans-etat)
REST étant un acronyme pour Representational State Transfer, le transfert d’état est une notion clé.
Conformément à l’architecture REST (Representational « State » Transfer), lors d’un échange entre le client
et le serveur, aucune information du client n’est conservée par le serveur, mis à part les informations
d’authentification pour celles qui en ont besoin, Cette restriction est appelée stateless. Chaque requête est
traitée indépendamment et le serveur ne sauvegarde pas l’état de la session de l’utilisateur. Seules les
données nécessaires à la réalisation de la demande sont à fournir par le client. Le fait d’être Stateless peut
également permettre une meilleur “scalabilité” du serveur puisqu’il n’a pas à gérer les sessions. Les
données habituellement stockées en sessions par le serveur, doivent donc être stockées coté client.
 Client serveur
Le modèle de conception client-serveur applique la séparation des préoccupations, ce qui aide le client et
les composants serveur à évoluer indépendamment.
En séparant les problèmes d’interface utilisateur (client) des problèmes de stockage de données (serveur),
nous améliorons la portabilité de l’interface utilisateur sur plusieurs plates-formes et améliorons l’évolutivité
en simplifiant les composants du serveur.
Pendant que le client et le serveur évoluent, nous devons nous assurer que l’interface entre le client et le
serveur ne se rompt pas.
 Système hiérarchisé par couche
Le style de système en couches permet à une architecture d’être composée de couches hiérarchiques en
limitant le comportement des composants.
Par exemple, dans un système en couches, chaque composant ne peut pas voir au-delà de la couche
immédiate avec laquelle il interagit.
 Code à la demande (Optionnel)
REST permet également d’étendre les fonctionnalités du client en téléchargeant et en exécutant du code
sous forme d’applets ou de scripts. C’est-à-dire le serveur doit être capable de transférer de la logique à un
client pour qu’il puisse l'exécuter.
Un exemple largement répandu dans le Web est l'exécution de scripts coté clients comme le JavaScript.
Le code téléchargé simplifie les clients en réduisant le nombre de fonctionnalités requises pour être pré-
implémentées. Les serveurs peuvent fournir une partie des fonctionnalités fournies au client sous forme de
code, et le client n’a besoin que d’exécuter le code
3. Le modèle de maturité de Richardson
REST tel que l’a défini Roy Fiedling n’est qu’une approche théorique. Dans la pratique il est quasiment im-
possible de respecter les 6 points qu’il a défini.
Leonard Richardson a créé un modèle permettant de mesurer la maturité d’une API REST. Son modèle est
composé de 4 niveaux. Plus une API a un niveau élevé, plus elle est en accord avec les principes REST.
Figure 3 : Illustration du modèle de maturité

de Richardson
Source : https://guide-api-rest.marmicode.fr/api-rest/le-modele-de-maturite-de-richardson
3.1 Niveau 0 : Le RPC sur http en POX
A ce niveau, qui constitue le point de départ du modèle, on ne peut pas vraiment parler de REST : on se
contente d’utiliser HTTP comme système de transport pour interagir à distance avec un « service ».
Toutes les requêtes sont envoyées vers le même endpoint (la même URI) : /gestionBookmark. Elles sont
complètement décrites dans le flux XML envoyé.
Une première requête est envoyée pour obtenir les créneaux disponibles à une date donnée :
Par exemple : une application de gestion de livre, Si l’on veut ajouter un livre
1 POST /gestionBookmark HTTP/1.1

2 Content-Type: application/json
3 ...
4
5 {
6 "creerBookmark": {
7 "titre": "Mon premier bookmark",
8 "url": "http://www.example.com" }
9 }
10
Si l’opération réussi on reçoit le contenu envoyé en réponse
1 HTTP/1.1 200 OK
3 ...
4
5 {
6 "bookmark": {
7 "id": 1,
10 }
11
Sinon on retourne une réponse négative
1 HTTP/1.1 200 OK
3 ...
4
5 {
6 "BookmarkImpossible": {
7 "erreur": "Impossible de créer le bookmark" }
8 }
9
10
Le niveau 0 correspond donc à un système RPC et on peut constater que l’on renvoie un status code “200
OK” même si le bookmark n’a pas été créé, ce qui n’est pas optimal.
3.2 Niveau 1 : l’utilisation de ressources différenciées
Dans le Richardson Maturity Model, le premier pas vers l’utilisation de REST consiste à introduire la notion
de ressource. Ce qui est somme toute assez logique, puisque REST est un modèle d’architecture basé sur
la manipulation de ressources (tout est ressource).
Ainsi, là où au niveau 0, toutes les requêtes étaient faites vers un unique endpoint (une unique URI), au ni-
veau 1, les requêtes sont envoyées à des ressources individuelles Pour notre exemple, on fera une requête
POST directement sur la ressource bookmark.
1 POST /bookmarks HTTP/1.1 Content-Type:

2 application/json
3 ...
4
5 {
6 "creerBookmark": {
9 }
10
3.3 Niveau 2 : L’utilisation des verbes HTTP et les codes de retour
Pour les 2 premiers niveaux, on utilisait des méthodes POST mais on aurait pu utiliser une autre méthode et
obtenir le même résultat. Le niveau 2 est atteint lorsque les méthodes HTTP sont utilisées telles que défi-
nies dans le protocole. GET pour la lecture, POST pour la création, PUT pour la modification et DELETE
pour la suppression.
Pour atteindre le niveau 2, il faut également envoyer les bons codes de retour. Par exemple, si l’on essaye
de modifier un bookmark qui n'existe pas, on ne renverra pas un code 200 OK mais plutôt un code 404 Not
Found.
3.4 Niveau 3 : Les liens Hypermédia
Le troisième et dernier niveau du Richardson Maturity Model introduit la notion de HATEOAS (Hypertext As
The Engine Of Application State). Derrière cet acronyme barbare se cache un principe simple : les transi-
tions possibles vers les états suivants sont fournies par des liens hypermédia.
Les requêtes sont les mêmes qu’au niveau 2, mais les réponses sont ici enrichies avec, pour chaque res-
source, un élément link fournissant l’URI permettant de la manipuler. Par exemple : Si l’on liste les book-
marks d’un utilisateur
<bookmarks>
<bookmark>
<id>42</id>
<link rel="self" href="http://livre.com/bookmarks/42" />
<link rel="author" href="http://livre.com/users/1337" />
</bookmark>
<bookmark>
<id>1645</id>
<link rel="self" href="http://livre.com/bookmarks/1645" />
<link rel="author" href="http://livre.com/users/1337" />
</bookmark>
<link rel="self" href="http://livre.com/user/1337/bookmarks" />
</bookmarks>
En d’autre terme le modèle de maturité de Richardson est un guide qui permet de bien comprendre les diffé-
rentes contraintes d’une API REST. Il faut cependant savoir rester pragmatique et ne pas, par exemple,
chercher à atteindre le niveau 3 si le client ne lit pas les liens dans les réponses de manière automatique.
4. Les méthodes HTTP en REST
Les API RESTful utilisent donc le protocole HTTP pour gérer les requêtes et ressources web. Cela veut dire
qu’elles doivent utiliser les verbes (ou méthodes) HTTP définis pour créer les API. Les verbes HTTP (ou
méthodes) primaires les plus couramment utilisés sont POST, GET, PUT et DELETE. Ceux-ci corres-
pondent respectivement à créer, lire, mettre à jour et supprimer des ressources. Cela correspond au fameux
CRUD (Create, Read, Update, Delete). Ce sont ces méthodes qui vont permettre de manipuler les res-
sources Il existe un certain nombre d'autres verbes qui sont aussi utilisés mais moins fréquemment
Voici la liste des principales méthodes, et leurs utilisations normées :
URI (exemple) GET POST PUT DELETE PATCH
Modifie entiè- Modifie partielle-

Récupère les Crée un Supprime
rement l’utilisa- ment l’utilisateur
données de utilisateur l’utilisa-
teur d’identi- 42 avec les infor-
http://api.exemple.com/users/42 l’utilisateur avec teur
fiant 42 avec de mations envoyées
d’identifiant l’identi- d’identi-
nouvelles don- (modification ci-
42 fiant 42 fiant 42
nées blée)
Tableau 2 : Liste des principales méthodes
Ce sont les verbes qu’on retrouve la plupart du temps sur des back-end utilisant REST. Cependant, il en
existe d’autres, beaucoup moins utilisés, voire peu ou pas connus :
 HEAD : Fais la même requête que le GET, mais sans renvoyer le body de la réponse (seulement
l’en-tête) ;
 CONNECT : ce verbe établit un tunnel vers la ressource ciblée ;
 OPTIONS : cette méthode est utilisée pour décrire les options de communications avec l’API cible ;
 TRACE : Réalise un message de test vers la ressource (API) ciblée.
Exemple D’utilisation
GET
1 HTTP/1.1 200 OK
3 ...
4
5 {
6 "id": 42,
7 "titre": "Mon 42ème bookmark",
8 "url":
9 "http://www.example.com"
10 }
La méthode HTTP GET est utilisée pour récupérer (ou lire) une représentation d'une ressource. En cas de
succès, elle retourne une représentation en XML ou JSON et un status code de 200 OK. En cas d'erreur,
elle renvoie le plus souvent une 404 Not Found ou 400 Bad Request.
PUT
La méthode de requête HTTP PUT crée une nouvelle ressource ou remplace une représentation de la res-
source cible par la charge utile de la requête.
Exemple de syntaxe : PUT /new.html HTTP/1.1
Exemple :
1
2
3 PUT /new.html HTTP/1.1
4 host: example/com
5 Content-type: text/html
6
7 ...
8
9 <p>new file<p>
10
Si la ressource cible n’a pas de représentation actuelle et que la requête PUT en crée une avec succès, le
serveur d’origine doit en informer l’agent utilisateur en envoyant une réponse 201 (Créé).
HTTP/1.1 201 Create
1
2
3
HTTP/1.1 201 created
4
Content-location: /new file
5
Content-type: text/html
6
7
8
9
10
Si la mise à jour réussit, PUT doit retourner un status code 200 OK (ou 204 No Content si on ne re-
tourne rien dans le corps).
POST
La méthode POST est plus souvent utilisée pour la création de nouvelles ressources.
Cette requête créera un nouveau livre avec les informations contenues dans le corps de la requête :
1 POST /api/bookmarks HTTP/1.1 Content-Type:

2 application/json
3 ...
4
5 {
6 "titre": "Mon premier Livre modifié",
7 "url": "http://www.example.com"
8 }
9
Si la création est réussie, elle doit retourner un status code 201 Created et rediriger l’utilisateur vers la
nouvelle ressource qui vient d’être créée.
DELETE
La méthode de requête HTTP DELETE supprime une ressource identifiée par un URI
1 DELETE /api/bookmarks/42 HTTP/1.1 Content-Type:

2 application/json
3 ...
Lors d’une requête DELETE, si la suppression de la ressource a bien été effectuée, il faut retourner une ré-
ponse avec un statut HTTP 200 OK. Il est également possible de retourner un status HTTP 204 No Content
avec un corps vide.
OPTION
La méthode HTTP OPTIONS demande les options de communication autorisées pour une URL ou un
serveur donné. Un client peut spécifier une URL avec cette méthode ou un astérisque (*) pour faire
référence à l’ensemble du serveur.
Lors d’une requête OPTION sur une URI, la réponse contient une en-tête “Allow”.
Cette en-tête est constituée d’une liste de méthodes qui sont supportées par la ressource.
Cette méthode permet donc au client de déterminer les options et les méthodes associées à la ressource
sans exécuter d’action sur la ressource et sans la récupérer.
Méthodes En cas de succès En cas d’échec

GET 200 OK 400 Bad Request
404 Not Found
PUT 200 OK 400 Bad Request
404 Not Found
409 Conflict
POST 201 Created 400 Bad Request
Redirection vers l’URI de
l’objet
DELETE 200 OK 400 Bad Request
404 Not Found
410 Gone
Tableau 3 : Exemples de codes de retour par Action en fonction du résultat
4. CONCEPTION D’UNE API REST

FIGURE4 : STRUCTURE D’UNE API REST

Source : Exemples d'API REST en PHP (nicolashachet.com)
Les services Web basés sur REST peuvent produire une sortie dans n’importe quel format, tel que CSV,
JSON, RSS, etc. Cela dépend donc du format que vous souhaitez analyser avec votre langage de
programmation. Dans ce mémoire, nous allons créer une API REST à l’aide du langage PHP.
Nous allons réaliser en PHP l’implémentation d’un service REST la gestion de produit qui aura la requête
HTTP Get, Post, Put et Delete pour récupérer, ajouter, mettre à jour et supprimer les enregistrements de
MySQL. Les détails de l’API rest sont les suivants:
Route Méthode Type Description

http://127.0.0.1/api/produits GET JSON Récupérer toutes les produits.
http://127.0.0.1/api/produits/{id} GET JSON Récupérer les données d’un seul produit
http://127.0.0.1/api/produits POST JSON Insérer un nouveau produit dans la base de données.
http://127.0.0.1/api/produits/{id} PUT JSON Mettre à jour un produit dans la base de données.
http://127.0.0.1/api/produits/{id} DELETE JSON Supprimer un produit de la base de données.
Tableau 4: Les détails de notre API REST
Nous allons utiliser les fichiers suivants pour notre travail:
index.php: Ce fichier est un fichier d’entrée. Ce fichier empêche la navigation dans les fichiers de répertoire.
db_connect.php: Ce fichier utilisera la chaîne de connexion MySQL.
produits.php: Ce fichier contient toutes les méthodes d’API REST.
post.php: Ce fichier permet d’envoyer une requête POST à notre API REST pour tester l’ajout d’un nouveau
produit.
put.php: Ce fichier permet d’envoyer une requête PUT à notre API REST pour tester la mise à jour d’un
nouveau produit.
delete.php: Ce fichier permet d’envoyer une requête DELETE à notre API REST pour tester la suppression
d’un nouveau produit.
.htaccess: Ce fichier est utilisé pour le routage.
Création de la table des produits:
Figure : Illustration de la creation de la table des produits
Ajout du fichier .Htaccess

Nous allons créer le fichier .htaccess et écrire une règle pour accéder à l’API Rest avec des URLs propres.
Pour cela, nous ajouterons les règles suivantes,
RewriteEngine On # Activer le module Rewrite

RewriteRule ^produits/?$ produits.php [NC,L]
RewriteRule ^[^/]+/(\d+)$ produits.php?id=$1
Connexion à la base de données MySQL avec PHP
Après avoir créé la table « produit », nous allons créer le fichier db_connect.php pour établir une connexion
avec la base de données MySQL.
<?php
$server = "localhost";
$username = "root";
$password = "";
$db = "stock";
$conn = mysqli_connect($server, $username, $password, $db);
?>
Récupérer tous les enregistrements de MySQL avec l’API REST
Nous allons créer une requête HTTP de type GET pour accéder à tous les enregistrements de produits à
partir de MySQL. Nous allons utiliser une requête MySQL pour récupérer les données de la table « produit »
et envoyer les données JSON au client en tant qu’objet.
Nous allons maintenant créer le fichier produits.php et inclure le fichier de connexion MySQL pour accéder
aux données de la base de données.
<?php
// Se connecter à la base de données
include("db_connect.php");
$request_method = $_SERVER["REQUEST_METHOD"];
...
?>
Nous avons également utilisé la méthode $_SERVER pour accéder aux informations sur l’action, comme
l’ajout, la modification ou la suppression.
Dans le même fichier, Nous allons « switcher » entre les méthodes de requête ( comme GET, POST,
DELETE et PUT) à l’aide de l’instruction « switch » en PHP :
<? php
switch ($request_method)
{
case 'GET':
if (!empty($_GET["id"]))
{
// Récupérer un seul produit
$id = intval ($_GET ["id"]);
getProducts ($id);
}
else
{
// Récupérer tous les produits
getProducts ();
}
break;
default:
// Requête invalide
header("HTTP/1.0 405 Method Not Allowed");
break;
}
?>
Nous avons créé une requête GET pour extraire toutes les données relatives aux produits de la base de
données MySQL. Pour les données relatives à un seul produit, nous transmettons l’id du produit. Nous
avons défini la méthode getProducts() afin que nous puissions créer une méthode comme ci-dessous:
<?php
function getProducts()
{
global $conn;
$query = "SELECT * FROM produit";
$response = array();
$result = mysqli_query($conn, $query);
while($row = mysqli_fetch_array($result))
{
$response[] = $row;
}
header('Content-Type: application/json');
echo json_encode($response, JSON_PRETTY_PRINT);
}
?>
La méthode mysqli_query() récupère les données de la table « produit » de MySQL et les stocke comme
abject dans la variable ‘result’. La méthode json_encode() convertit un tableau en json.
Maintenant, on accède à l’url « http://127.0.0.1/api/produits » et vous obtiendrez un enregistrement de tous

les produits de la table « produit ». Comme illustré dans l’image ci-dessous :
Figure : enreg
Récupération d’un seul produit avec l’API REST
Nous allons créer une requête de type HTTP GET pour accéder à un seul enregistrement de produit à partir
de la base de données MySQL via php.
function getProduct($id=0)
{
global $conn;
$query = "SELECT * FROM produit";
if($id != 0)
{
$query .= " WHERE id=".$id." LIMIT 1";
}
$response = array();
$result = mysqli_query($conn, $query);
while($row = mysqli_fetch_array($result))
{
$response[] = $row;
}
echo json_encode($response, JSON_PRETTY_PRINT);
}
Création d’un nouvel enregistrement dans la base de donnée MySQL
Nous allons créer une nouvelle Api Reste pour insérer un nouveau produit dans MySQL en utilisant php.
Nous allons créer une requête de type POST car nous publierons des données JSON sur le serveur.
Nous allons ajouter un nouveau cas dans le bloc « Switch » comme indiqué ci-dessous :
<?php
...
case 'POST':
// Ajouter un produit
AddProduct();
break;
...
?>
Nous allons maintenant créer la méthode AddProduct() dans le fichier « produits.php ».
<?php
function AddProduct()
{
global $conn;
$name = $_POST["name"];
$description = $_POST["description"];
$price = $_POST["price"];
$category = $_POST["category"];
$created = date('Y-m-d H:i:s');
$modified = date('Y-m-d H:i:s');
echo $query="INSERT INTO produit(name, description, price, category_id, created, modified) VALUES('".
$name."', '".$description."', '".$price."', '".$category."', '".$created."', '".$modified."')";
if(mysqli_query($conn, $query))
{
$response=array(
'status' => 1,
'status_message' =>'Produit ajoute avec succes.'
);
}
else
{
$response=array(
'status' => 0,
'status_message' =>'ERREUR!.'. mysqli_error($conn)
);
}
echo json_encode($response);
}
?>
Nous allons maintenant tester notre API Rest pour ajouter un nouveau produit en envoyant une requête
POST, pour cela nous allons créer le fichier « post.php » et en ajoutant le code suivant.
<?php
$url = 'http://127.0.0.1/api/produits';
$data = array('name' => 'PEC', 'description' => 'Pencil 2H', 'price' => '2.25', 'category' => '9');
// utilisez 'http' même si vous envoyez la requête sur https:// ...
$options = array(
'http' => array(
'header' => "Content-type: application/x-www-form-urlencoded\r\n",
'method' => 'POST',
'content' => http_build_query($data)
)
);
$context = stream_context_create($options);
$result = file_get_contents($url, false, $context);
if ($result === FALSE) { /* Handle error */ }
var_dump($result);
?>
Maintenant, on accède à l’url « http://127.0.0.1/api/post.php », et on observe un nouvel enregistrement de

produit est inséré dans la table des produits, et sur le navigateur vous aurez le résultat suivant :
Modification d’un enregistrement dans la base de donnée MySQL
Nous allons créer une nouvelle requête HTTP PUT pour mettre à jour les données dans la base de données
MySQL.
<?php
...
case 'PUT':
// Modifier un produit
$id = intval($_GET["id"]);
updateProduct($id);
break;
...
?>
Maintenant, nous allons créer la méthode updateProduct() dans le fichier « produits.php ». Nous allons
utiliser l’id du produit que nous voulons mettre à jour et deuxièmement, les données mises à jour au format
JSON.
Puisque PHP n’a pas de variable $_PUT similaire à $_GET et $_POST pour récupérer les valeurs
transmises, nous utilisons les flux d’entrée (input stream 'php://input') pour obtenir ces valeurs pour mettre à
jour un produit.
<?php
function updateProduct($id)
{
global $conn;
$_PUT = array(); //tableau qui va contenir les données reçues
parse_str(file_get_contents('php://input'), $_PUT);
$name = $_PUT["name"];
$description = $_PUT["description"];
$price = $_PUT["price"];
$category = $_PUT["category"];
$modified = date('Y-m-d H:i:s');
//construire la requête SQL
$query="UPDATE produit SET name='".$name."', description='".$description."', price='".$price."',
category_id='".$category."', modified='".$modified."' WHERE id=".$id;
{
$response=array(
'status' => 1,
'status_message' =>'Produit mis a jour avec succes.'
);
}
else
{
$response=array(
'status' => 0,
'status_message' =>'Echec de la mise a jour de produit. '. mysqli_error($conn)
);
}
}
?>
Nous allons maintenant tester notre API Rest pour mettre à jour le produit en envoyant une requête PUT via
cURL, pour cela nous allons créer le fichier « put.php » et en ajoutant le code suivant.
<?php
$url = "http://127.0.0.1/api/produits/1"; // modifier le produit 1
$data = array('name' => 'MAC', 'description' => 'Ordinateur portable', 'price' => '9658', 'category' => '2');
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PUT");
curl_setopt($ch, CURLOPT_POSTFIELDS,http_build_query($data));
$response = curl_exec($ch);
var_dump($response);
if (!$response)
{
return false;
}
?>
Maintenant, on accede à l’url « http://127.0.0.1/api/put.php », et on observe que le produit en question a été

mis à jour dans la table des produits, et sur le navigateur vous aurez le résultat suivant :
Suppression d’un enregistrement dans la base de donnée MySQL
Nous allons créer une nouvelle requête d’API REST de type DELETE utilisant PHP pour supprimer un
produit de la base de données MySQL. Nous transmettons l’id du produit que vous souhaitez supprimer en
tant que paramètres.
<?php
...
case 'DELETE':
// Supprimer un produit
$id = intval($_GET["id"]);
deleteProduct($id);
break;
...
?>
Nous allons maintenant créer la méthode deleteProduct() dans le fichier « produits.php ». Nous utiliserons
l’id pour supprimer l’enregistrement de la table « produit ».
<?php
function deleteProduct($id)
{
global $conn;
$query = "DELETE FROM produit WHERE id=".$id;

{
$response=array(
'status' => 1,
'status_message' =>'Produit supprime avec succes.'
);
}
else
{
$response=array(
'status' => 0,
'status_message' =>'La suppression du produit a echoue. '. mysqli_error($conn)
);
}
}
?>
Nous allons maintenant tester notre API Rest pour supprimer le produit en envoyant une requête DELETE
via cURL, pour cela nous allons créer le fichier « delete.php » et en ajoutant le code suivant.
<?php
$url = "http://127.0.0.1/api/produits/1"; // supprimer le produit 1
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "DELETE");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);
var_dump($response);
curl_close($ch);
?>
5.CONCLUSION
Nous avons vu que les Web Services REST étaient de plus en plus utilisés au détriment des services
SOAP. Cela est dû à leur simplicité et leur utilisation de notions déjà bien connues par les développeurs : le
protocole HTTP et les URI.
Une architecture REST offre de nombreux avantages tels quel la scalabilité de l’application ou le fait d’être
indépendant du langage dans lequel elle est développée. Cependant, il n’existe pas d’architecture standard
REST. Il y a donc une part d'interprétation sur ce que REST doit être. Plusieurs auteurs ont des points de
vue différents sur les contraintes à respecter pour qu’un Web Service soit RESTful.
Le développeur souhaitant mettre en place une telle API va donc devoir se faire sa propre idée de REST en
étudiant le point de vue de différents auteurs sur le sujet. Les contraintes REST de Roy Fielding constituent
un très bon point de départ. Elles fournissent également une bonne base pour programmer une API REST
sans avoir de connaissances préalables.
Le Modèle de Maturité de Richardson permet, quant à lui, de mesurer le niveau de conformité de son API
REST. Cela permet de hiérarchiser les contraintes en fonction de leur importance.
BIBLIOGGRAPHIE ET WEBOGRAPHIE
● REST sur Wikipédia

● Exemples d'API REST en PHP (nicolashachet.com)
● www.developer.mozilla.org
● Qu'est-ce qu'une API REST ? - France | IBM
● Définition de l'API REST : que sont les API REST (API RESTful) ? (astera.com)
● Postman
● API Platform: The API-first framework (REST, GraphQL and real-time) (api-platform.com)
● RESTful Web Services, par Leonard Richardson et Sam Ruby, est un ouvrage en anglais sorti en mai 2007. Celui-ci a popularisé le
style d’architecture REST

Sk's Memory

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sk's Memory

Transféré par

Droits d'auteur :

Formats disponibles

Réalisé par Kouame Samuel Etudiant en science informatique

Ministère de la Communication de l’Economie Numérique

Institut des technologies et des spécialités

Année académique : 2021 / 2022

MEMOIRE DE FIN DE CYCLE POUR L’OBTENTION DE LA

DEVELOPPEMENT D’UN API REST EN

A mon Père et ma Mère:

 Monsieur DJEGRE, d’ITES 2PLATEAUX.

 Le Corps Enseignant et le Personnel Administratif de l’Institut des technologies et spécialités(ITES),

LISTE DES FIGURES

Figure 1 : Répartition des protocoles utilisés par les API.…………12

Figure 2 : Illustration d’une Architecture Rest……………………14

Figure 3 : Illustration du modèle de maturité de Richardson……21

Figure 4: Structure d’une API REST…………………………………..31

LISTE DES TABLEAUX

Tableau 2: Liste des principales méthodes……………………………………………25

Tableau 3: Exemples de codes de retour par Action en fonction du résultat….29

Tableau 4 : Détails de l’API REST…………………………………………………………………………31

La liste ci-dessous contient toutes les abréviations utilisées dans ce document.

API Application Programming Interface

C# C sharp (langage de programmation orienté objet)

CRUD Create Read Update Delete

DCE/RPC Remote Procedure Calls

HATEOAS Hypermedia As The Engine Of Application State

Hypertext Markup Language

Java Langage de programmation orienté objet

JSON JavaScript Object Notation

REST Representational State Transfer

SMTP Simple Mail Transfer Protocol

SOAP Simple Object Access Protocol

URI Uniform Resource Identifier

URL Uniform Resource Locator

XML Extensible Markup Language

JAVASCRIPT Langage de programmation orienté objet

PHP/RUBY Langage de programmation orienté objet

1. Les Web Services

2. État des lieux de la situation

Figure 1 : Répartition des protocoles utilisés par les API

Nous allons ainsi avancer autour de 3 points majeurs :

● comprendre les principes fondamentaux de REST

● montrer comment développer une API REST

2. LES BASES DE REST

2.1 Qu’est-ce que REST

Figure 2 : Illustration d’une Architecture Rest

LES CONCEPT UTILISES PAR REST

Par exemple : Recherche de la liste des livres

Exemples de représentations en XML et JSON d’un utilisateur :

2. Principes clés du REST

2.1Les concepts utilises par REST

Par exemple : API/utilisateurs.

 Messages auto-descriptifs : chaque message comprend suffisamment d’informations pour décrire

 Système hiérarchisé par couche

 Code à la demande (Optionnel)

3. Le modèle de maturité de Richardson

Figure 3 : Illustration du modèle de maturité

3.1 Niveau 0 : Le RPC sur http en POX

1 POST /gestionBookmark HTTP/1.1

Si l’opération réussi on reçoit le contenu envoyé en réponse

Sinon on retourne une réponse négative

3.2 Niveau 1 : l’utilisation de ressources différenciées

1 POST /bookmarks HTTP/1.1 Content-Type:

3.3 Niveau 2 : L’utilisation des verbes HTTP et les codes de retour

3.4 Niveau 3 : Les liens Hypermédia