API REST : qu’est ce que c’est et comment développer des API restful ?

Dans le monde où nous vivons actuellement, nous générons de plus en plus d’informations à travers tout ce que nous entreprenons sur le web. L’existence des API REST est entre autres les sources de la génération de ces multitudes de données.

En effet, plusieurs services, comme nous en avons discuté dans la chronique concernant l’architecture SOA, nécessitent l’utilisation d’une ou de plusieurs API REST pour interagir avec les utilisateurs de celles-ci. En outre, les Data Engineer, les Data Scientists et les Data Analysts, pour récupérer et analyser les données volumineuses, ont besoin d’API afin d’effectuer les traitements adéquats.

Dans ce tutoriel exhaustif, nous allons traiter le sujet d’API REST de long en large, et nous vous montrerons comment en développer une.

1 – Qu’est-ce qu’une API ?

Supposons que vous souhaitiez retrouver une information (une vidéo par exemple) sur une plateforme (prenons comme exemple Facebook). Pour ce faire, vous allez taper sur la barre de recherche du site, cliquer sur le bouton prévu à cet effet et vous allez recevoir une liste de réponses correspondant aux critères que vous avez mentionné.

Une API utilise le même procédé, c’est-à-dire qu’il demande des informations d’entrée pour renvoyer en retour des résultats liés à cette demande.

En réalité, l’API ou Application Program Interface est, comme son nom l’indique, une interface servant à communiquer entre deux ou plusieurs applications (appareils, services, etc.) distinctes. Elle permet d’effectuer une requête spécifique et de recevoir une réponse, formulée sous un format établi.

Elle se base donc sur une architecture client-serveur, sur laquelle le client est celui qui effectue la demande et le serveur, celui qui traite et renvoie la réponse. Le client n’a pas à se soucier de la manière dont ce traitement est fait, mais récupère juste ce qu’il a demandé. Le programme du côté du serveur peut donc être élaboré et écrit en n’importe quel langage. Cela n’affectera pas la réponse obtenue par le client, et ce, quelles que soient les technologies utilisées par celui-ci. Il suffit que ces technologies puissent interpréter le résultat communiqué et le tour est joué.

Grâce à cette interface, les développeurs diminuent le volume de code à produire en n’effectuant que les liens entre les différentes APIs nécessaires pour leurs programmes et adaptés à leurs besoins et à ceux de l’entreprise.

Les API permettent également de réutiliser à mainte reprise la même ressource, ce qui offre une flexibilité importante à chaque ressource.

On retrouve les APIs dans presque tous les domaines nécessitant une interaction extérieure, que ce soit au niveau d’un navigateur, d’un système d’exploitation ou bien d’un site internet. Des géants du web tels que Google, Twitter, LinkedIn ou encore Amazon intègre des APIs au sein de leurs sites et de leurs services.

Les APIs peuvent être publiques, c’est-à-dire, ouverte à toutes personnes et applications souhaitant y accéder. Parfois, ce genre d’API nécessite une clé d’authentification pour pouvoir y accéder. Cependant, il en existe certaines qui sont complètement ouvertes.

Elles peuvent également être privées, c’est-à-dire accessible qu’au sein même des applications d’une entreprise.

2 -Historique et évolution des APIs

Microsoft est l’un des précurseurs de l’API, car l’entreprise a commencé à l’introduire au sein de son système depuis 1985. En effet, cette grande société a utilisé des interfaces depuis cette époque afin de permettre aux développeurs de participer aux développements de leurs systèmes. Toutefois, l’utilisation du terme API remonte d’encore plus loin, vers les années 1960 et 1970.

À ses débuts, la manière la plus populaire d’interagir avec les APIs était à travers le protocole SOAP (Simple Object Access Protocol) en utilisant essentiellement du XML lors de cet échange. Cependant, d’autres protocoles et normes ont tenté de s’imposer tels que COBRA, COM ou DCOM.

En 2000, lors de sa thèse pour son doctorat à l’université de Californie, Roy Fielding évoque pour la première fois la notion d’API REST, qui devient par la suite, et ce jusqu’à nos jours, la référence en matière d’interrogation d’une ressource distante.

À partir de ce moment, plusieurs firmes ont conçu leurs propres API, en commençant par Salesforce, qui a lancé plusieurs APIs en XML pour leurs SaaS en février 2000.

Vient ensuite, quelques mois plus tard, le tour d’eBay de lancer ses APIs, et cette fois-ci, elle privilégie l’API REST qui semble être la meilleure manière d’aborder les interfaces, mais nous allons y revenir plus tard. Elle propose de nos jours plusieurs APIs REST telles que l’eBay Trading API, l’eBay Finding API, etc.

Plusieurs enseignes se sont également intéressées à l’utilisation des APIs et ont mis en place leurs interfaces à l’instar de Delicious en 2003 ou encore de Flickr en 2004.

Les réseaux sociaux se sont lancés dans cette pratique aussi en 2006. Facebook, par exemple, a mis en place le Facebook Development Platform. La même année, Amazon est également entrée dans le monde de la création d’API REST et par la même occasion lancé l’Infrastructure-as-Service.

De nos jours, on retrouve les APIs, en particulier les APIs REST, partout au sein de diverses applications, sites, logiciels et autres programmes. Tout le monde les utilise afin d’optimiser la performance de leurs créations.

Qu’est-ce qu’une API REST ?

Maintenant que nous connaissons la définition de l’API ainsi que son histoire, intéressons-nous au vif du sujet, à savoir l’API REST.

Le mot REST est l’abréviation de Representational State Transfer. Une API est dite RESTful lorsqu’elle répond à certaines contraintes architecturales. En gros, c’est un ensemble de règles à respecter afin de rendre l’interaction entre le client et le serveur le plus flexible, le plus simple et le plus rapide possible. C’est pour cela que les entreprises la préfèrent aux autres manières de faire appel à des APIs.

Elle se base essentiellement sur le protocole HTTP pour l’envoi de requêtes relatives au CRUD (création, récupération, modification ou suppression). L’interaction avec les ressources basées sur un serveur s’effectue à partir d’un URI. Cet URI ressemble à ceci :

http://localhost:9200/clients

Quant à la réception des données, il existe plusieurs formats dans lesquels ces dernières peuvent être retournées, à savoir : JSON, XML, XLT, YAML ou HTML. Pour l’exemple précédent, qui est tiré de notre article sur ElasticSearch, la réponse est :

{
    "clients" : {
        "aliases" : {},
        "mappings" : {},
        "settings" : {
            "index" : {
                "creation_date" : "1485532333694",
                "number_of_shards" : "5",
                "uuid" : "YNRWdEchTPGdAgPn5_tUPA",
                "version" : "5010299"
            },
            "provided_name" : "clients"
        }
    }
  }

À quoi sert une API REST ?

Si vous êtes une personne qui développe des outils informatiques, notamment des applications liées au web, vous serez sans doute emmené à utiliser une ou plusieurs API REST pour compléter certains projets.

Le rôle premier d’une API REST est de servir d’intermédiaire entre le client et le serveur. C’est-à-dire que c’est elle qui réceptionne les requêtes émises par le client, le transmet à l’entité demandée au serveur, prend les réponses données par ce dernier puis les retransmettent au client.

Grâce à ce rôle principal, beaucoup de portes se sont ouvertes et les possibilités d’applications ont augmenté offrant de nouvelles opportunités. Nous pouvons, par exemple citer son rôle pour faciliter l’accès à de nombreuses sources d’informations à travers une simple requête.

En effet, en faisant appel à une URI, nous pouvons récupérer une quantité importante de données. Cela offre de grands avantages pour les deux parties : les clients peuvent augmenter la performance de leurs applications et de leurs sites. Quant aux serveurs, ils gagnent en visibilité et multiplient leurs chiffres d’affaires en offrant, par exemple, un abonnement pour pouvoir consommer leurs API REST.

Il faut également savoir qu’une seule API REST peut alimenter plusieurs applications sans aucun souci. Ce qui veut dire que le temps et la ressource utilisées sont fortement réduits.

Cela nous ramène à son rôle dans les interactions sur le cloud qui est facilité notamment par le fait qu’elle ne change pas l’état actuel de la solution, ce qui la rend très flexible et parfaite.

En plus, c’est une manière idéale de sécuriser les applications pour les deux parties concernées, car les interactions directes pouvant entrainer de fausses manipulations sont évitées au maximum.

Quels sont ses intérêts pour le Big Data ?

Comme nous l’avons dit au tout début de cette chronique, les APIs REST sont au cœur de l’expansion du Big Data. En effet, plusieurs requêtes transitant à travers une API REST servent à enrichir les bases de données massives pour que, par la suite, nous puissions effectuer des traitements aidant à la prise de décision.

Toutefois, il n’y a pas que l’enrichissement du Data Warehouse ou du Data Lake qui fait que les APIs REST sont utiles au Big Data car, en effet, ces interfaces permettent :

• De faciliter l’extraction des données venant de plusieurs sources différentes ;
• D’obtenir une quantité importante de données en temps réel ;
• D’effectuer un traitement et une analyse plus rapides ;
• D’accéder à des ressources de différents formats ou de récupérer ces dernières, ce qui est entre autre à la base du principe du Big Data lui-même ;
• D’implémenter des fonctionnalités supplémentaires comme du Machines Learning sans pour autant le développer. D’ailleurs, ces fonctionnalités peuvent évoluer et être modifiées par le concepteur du côté serveur sans impacter le programme côté client ;
• De limiter le volume de l’entrepôt de données qu’il faut mettre en place, puisque l’on peut effectuer une analyse en amont pour ne stocker que les données pertinentes à l’entreprise.

D’ailleurs, si vous souhaitez approfondir vos connaissances en Big Data, nous vous offrons cette formation sur le Big Data Streaming :

Principes de base d’une API 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.

L’architecture client-serveur

Nous avons vu cet aspect à mainte reprise depuis le début de cette chronique. Mais c’est nécessaire d’apporter plus de précision sur ce point.

Dans une API RESTful, le client et le serveur effectuent leurs traitements indépendamment. Cela veut dire que chaque protagoniste peut manipuler leurs programmes sans impacter les fonctionnalités de l’autre. Tant la communication entre eux est maintenue, tout va bien. Cette communication s’effectue essentiellement à travers des requêtes HTTP.

C’est grâce à ce principe que plusieurs applications situées sur plusieurs plateformes différentes peuvent échanger avec le même API REST et recevoir chacune les réponses attendues.

Sans état

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. 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 qu’une API REST soit stateless permet au serveur de traiter plusieurs requêtes venant de plusieurs utilisateurs différents sans subir une saturation qui risque de le planter.

Cacheable

Afin de limiter les appels au serveur et éviter de le surcharger, une API REST doit permettre de sauvegarder certaines informations en cache. Donc, le client peut réutiliser des ressources précédemment fournies par le serveur si cela s’avère utile.

Cependant, l’API REST doit spécifier la durée de mise en cache ainsi que la nature des informations pouvant accepter ce procédé pour maintenir la véracité de ces dernières.

Interface uniforme

Une API REST doit se soumettre à une architecture spécifique que le client et le serveur doivent absolument 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 autodescriptives et l’utilisation de l’hypermédia comme moteur de l’état de l’application. D’ailleurs, nous allons détailler ces deux dernières contraintes sous peu.

Système en couches

Une API REST peut contenir plusieurs systèmes en couches, c’est-à-dire qu’il peut y avoir plusieurs serveurs qui travaillent ensemble pour élaborer la réponse finale demandée par le client. Cette architecture offre plusieurs avantages à savoir une sécurité importante des données échangées par les deux parties, car les interactions se limitent entre les couches qui se suivent, une grande flexibilité et une évolutivité des applications.

Code à la demande

Cette contrainte, qui est optionnelle, veut dire que l’API REST peut fournir du code exécutable aux clients au lieu des réponses conventionnelles. Ces codes peuvent être des scripts ou des applets. De ce fait, les clients peuvent étendre les fonctionnalités de leurs applications ou de leurs sites sans avoir à pré-implémenter certaines méthodes ou modules. Ce qui facilite grandement la vie des programmeurs.

Bonus : HATEOAS et autodescriptif

Dans la section interface uniforme, nous avons cité ces deux contraintes. Cependant, elles méritent de s’y attarder brièvement.

HATEOAS ou Hypermedia As The Engine Of Application State signifie que l’on peut obtenir d’autres liens vers d’autres API REST dans la réponse fournie par celle que nous avons sollicitée. Certes, les liens en question peuvent être retrouvés si le concepteur de l’interface possède une bonne documentation, cependant, cela rend la tâche moins fastidieuse pour les clients.

Le terme autodescriptif signifie que l’API REST doit spécifier la manière dont les résultats qu’elle fournit peuvent être interprétés. Nous pouvons donc retrouver des spécifications telles que application/json, text/css, video/mp4, etc. dans la réponse à notre requête.

Fonctionnement d’une API RESTful

Afin de comprendre le fonctionnement d’une API REST, il faut connaitre les notions qui composent cette dernière à savoir : le client, le serveur, les ressources les méthodes et les Endpoint.

Le client

Le client, en gros, est celui qui a besoin d’informations et qui en effectue la demande. Prenons par exemple votre navigateur, lorsque vous surfez sur un site, il sollicite les APIs de ce dernier afin que vous puissiez visualiser chaque page. Ici, il est donc le client. Un autre exemple est, lorsque vous recherchez l’hôtel le plus proche sur un site de réservation, ce site vous montrera sûrement une carte tirée de Google Map afin que vous obteniez une adresse. Ce site est donc le client de l’API Google Map.

Le serveur

Le serveur est celui qui répond à la demande du client, c’est-à-dire qu’il traite les requêtes que le client envoie et lui renvoie les informations qu’il demande. Si nous reprenons les deux exemples ci-dessus, le navigateur effectue une requête sur le serveur du site sur lequel vous êtes et pour le deuxième exemple, le serveur est Google Map, car c’est lui qui offre la possibilité de visualiser la carte.

Les ressources

Grâce aux deux sujets que nous venons de traiter, vous pouvez sans doute en déduire que les ressources sont les informations qui transitent entre ces deux entités. En effet, toutes informations, demandes et réponses sollicitées au sein d’une API REST sont appelées des ressources. Une ressource peut donc se présenter sous différents formats. Il peut s’agir d’un document (texte, Word, Excel, etc.), d’une image, d’une vidéo, ou même d’un autre lien.

Les méthodes

Les méthodes de ressources correspondent aux différents types de traitements que nous pouvons effectuer lors d’une requête API REST. Il existe principalement 4 méthodes courantes, qui correspondent aux méthodes CRUD, à savoir :

POST : la méthode qui sert à publier, envoyer des informations au serveur ;

GET : celle pour récupérer des informations venant du serveur. Elle peut retourner plusieurs formats de réponses, comme nous l’avons souvent répété au cours de cette chronique ;

PUT : il s’agit de la méthode à utiliser lorsque l’on effectue une mise à jour auprès d’un serveur ;

DELETE : qui, comme son nom l’indique permet de supprimer une entrée sur un serveur.

Cependant, il existe d’autres méthodes que l’on peut utiliser lors d’un appel d’une API REST comme PATCH, HEAD, OPTIONS, TRACE et CONNECT.

Les Endpoint

Afin que le client et le serveur puissent communiquer, afin que les ressources puissent être échangées auprès de ces deux parties et afin que les méthodes puissent être appliquées, il faut un moyen de communication. Les Endpoint sont justement ce moyen. C’est une manière de nommer les liens sur lesquels pointe l’API. En d’autres termes, il s’agit des adresses des serveurs, qui sont suivis des méthodes à adopter ainsi que d’autres paramètres supplémentaires comme les filtres, les catégories de ressources, etc.

API REST vs SOAP

Nous avons souvent évoqué SOAP tous le long de cette chronique. Mais qu’est-ce qui fait que ces deux types/architectures d’API soient souvent comparés et pourquoi ? Nous allons les confronter afin d’en connaitre la raison.

La première raison pour laquelle ces deux APIs sont comparées est sans doute que pendant très longtemps, avant l’apparition de l’API REST, SOAP a été la référence en termes d’utilisation des interfaces. En effet, ayant vu le jour en 1998, c’est un protocole se basant sur XML permettant d’interagir avec de nombreuses sortes d’autres protocoles tels que HTTP, UDP, TCP, etc.

Cependant, malgré cette puissance qu’il détient, SOAP a tendance à occuper plus de bande passante et par conséquent de devenir assez lent. De plus, il nécessite l’apprentissage du XML et une certaine coordination entre le concepteur du code client et serveur afin d’éviter les erreurs qui peuvent être fatales pour chacun d’eux. Il n’est donc pas assez flexible pour que les applications actuelles puissent évoluer.

C’est à cause de tout cela que, de nos jours, la plupart des développeurs privilégient l’utilisation d’une API RESTful.

Les APIs REST publiques

La notion d’API REST publique est très importante à retenir, surtout pour ceux qui souhaitent interagir avec le Big Data. En effet, les Open APIs sont de plus en plus utilisés de nos jours et offrent de multitudes d’opportunités, surtout pour ceux qui œuvrent dans le Big Data.

En fait, les opens APIs sont des interfaces de programmation ouvertes aux publics, c’est-à-dire que tout le monde peut disposer des ressources qu’elles contiennent. De nombreuses grosses firmes proposent leurs propres APIs publiques telles que Google, Amazon, GitHub, etc.

Pour une entreprise souhaitant diversifier et développer ses activités, ce sont des mines d’or à absolument exploiter. Elles permettent non seulement de récupérer des tonnes d’informations intéressantes, mais également d’effectuer directement des traitements et des analyses, et ce, en un laps de temps beaucoup plus court.

Des sites spécialisés tels que AnyAPI, Public APIs ou RapidAPI vont vous aider à retrouver des APIs REST intéressantes qui sont destinées aux personnes souhaitant développer un module supplémentaire pour son application ou bien pour celles qui font des métiers relatifs aux données volumineuses. Il faut noter que certaines de ces APIs nécessitent l’ouverture d’un compte auprès du fournisseur afin de pouvoir bénéficier des informations d’authentification nécessaires pour la consommation de leurs ressources.

Mise en pratique

Maintenant que nous avons vu tout ce qu’il faut savoir concernant les API REST, du moins en théorie, il est temps de passer à la pratique. Toutefois, nous vous invitons tout d’abord à consulter notre tutoriel sur la programmation informatique pour que vous puissiez connaitre quelques bases que nous allons appliquer dans cette section.

Créer une API REST

Avant de vraiment s’attaquer au développement à proprement parlé de l’API REST, il faut tout d’abord définir certains aspects à votre projet.

1^ère Étape : La documentation

En premier, pensez à la documentation que vous devriez fournir avec l’API REST en question. En effet, il est important de bien documenter l’interface de développement afin que ceux qui vont l’utiliser puissent facilement se retrouver. Vous devez retenir qu’il n’y aura pas que vous qui allez vous en servir. Dans cette documentation, vous devez spécifier tous les Endpoint et ce à quoi ils correspondent, les différents paramètres à inclure pour pouvoir obtenir des réponses ainsi que des exemples de réponses possibles pour chaque requête. Une documentation sur les erreurs qui sont susceptibles de se produire est également nécessaire.

2^nd Étape : Construction des Endpoint

Et en parlant des Endpoint, il est également important de les définir au préalable pour que vous puissiez visualiser dès le départ le rendu de votre API. Définissez les possibilités que vous souhaitez offrir aux utilisateurs, à savoir l’ajout, la modification, la mise à jour ou encore la suppression. En effet, il se peut que, pour une ressource donnée, toutes ces méthodes ne soient pas nécessaires ou, du moins, facultatives.

3^ème Étape : Choisir un Framework

Une fois que vous avez bien préparé votre projet, vous pouvez maintenant commencer à mettre en place votre API. Pour ce faire, vous devez choisir le Framework que vous allez utiliser.

Il existe plusieurs Frameworks basés sur de nombreux langages de programmation vers lesquels vous pouvez vous orienter. Il y a par exemple, Spring de Java, Express.js basé sur Node.js, Ruby on Rails de Ruby ou encore Flask de Python.

Dans cette chronique, nous allons utiliser Python avec comme Framework Django. Pour vous mettre dans le contexte et apprendre les bases nécessaires pour la suite de cette rubrique, nous vous conseillons de lire notre tutoriel sur la programmation Python.

Pourquoi Django ?

Nous avons choisi ce Framework, car il offre plusieurs avantages en matière de création d’API REST.

Tout d’abord, Django est un Framework facile à prendre en main, malgré le fait qu’il faut tout de même une notion en Python pour pouvoir le manipuler. Il est personnalisable à souhait et offre une flexibilité pour ses utilisateurs. En plus, la communauté autour de ce Framework est très active et pourra certainement vous aider en cas de blocage.

Plusieurs fonctionnalités sont déjà intégrées sur Django, notamment l’authentification ou encore la messagerie.

D’ailleurs, plusieurs entreprises de renom telles que YouTube ou Google utilisent ce Framework pour leur développement.

4^ème Étape : la création

Dans cet exemple, nous allons créer une API REST qui va traiter les titres et les catégories de cours. Nous allons procéder étape par étape pour que vous puissiez reproduire cela.

Création d’un nouveau répertoire

Tout d’abord, vous devez commencer par créer un répertoire dans lequel vous allez développer votre API. Pour cela, vous devez écrire les commandes qui suivent :

mkdir test_cours
cd test_cours

Mise en place d’un environnement virtuel

Il est important de créer un environnement virtuel pour que vous puissiez dissocier ce projet des autres projets que vous possédez. Pour ce faire, exécutez la commande suivante :

python -m virtualenv venv

Maintenant que l’environnement est créé, il faut l’activer avec la commande qui suit :

source venv/bin/activate

Si vous utilisez Windows comme système d’exploitation, la commande sera :

env/Scripts/activate.bat

Installation du Framework

Une fois arrivé à cette étape, vous devez maintenant installer les packages nécessaires, à savoir le framework Django et le framework Django Rest. Pour cela, vous devez exécuter la commande ci-dessous :

pip install django django-rest-framework

Création du projet

Ensuite, il faut que vous créiez le projet en lui-même à travers la commande suivante :

django-admin startproject test_cours .

Le « . » à la fin de l’instruction signifie que vous allez exécuter le projet dans le répertoire sur lequel vous vous situez actuellement. Il est donc important de ne pas l’oublier.

À partir de ce répertoire, créez un sous-répertoire que vous allez nommer api :

django-admin startapp api

Vous obtiendrez normalement une mise en page comme ceci :

$ pwd
/test_cours
$ find .
.
./manage.py
./test_cours
./test_cours/__init__.py
./test_cours/api
./test_cours/api/__init__.py
./test_cours/api/admin.py
./test_cours/api/apps.py
./test_cours/api/migrations
./test_cours/api/migrations/__init__.py
./test_cours/api/models.py
./test_cours/api/tests.py
./test_cours/api/views.py
./test_cours/settings.py
./test_cours/urls.py
./test_cours/wsgi.py

Vous devez par la suite ouvrir le fichier settings.py afin d’y ajouter votre application :

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'rest_framework',
    'api',
]

Définir un model

Vous devez définir un modèle pour les cours que vous souhaitez traiter. Pour cela, vous devez écrire le code suivant dans le fichier models.py de votre projet :

class Note(models.Model):
    title = models.CharField(max_length=50)
    category = models.CharField(max_length=100)
    def __str__(self):
        return self.title

Migration de la base de données

Il faut maintenant configurer votre base de données en le migrant pour la première fois à l’aide de ces commandes :

python manage.py makemigrations
python manage.py migrate

Création du premier utilisateur

Enfin, vous devez créer un premier utilisateur appelé admin en spécifiant son mot de passe. Pour cela, procédez comme suit :

python manage.py createsuperuser --email test@test.com --username admin
Password: ******** 
Password (again): ******** 
Superuser created successfully.

Serializers

Le serializer est la classe qui formatera les réponses que vous souhaitez. Tout d’abord, il faut créer un module appelé serializers.py au sein de votre projet :

cd test_cours/api && touch serializers.py

Ensuite, dans le cas de notre exemple, il faut écrire les codes suivants à l’intérieur de ce module :

from rest_framework import serializers
from .models import Cours
class CoursSerializer(serializers.ModelSerializer):
    class Meta:
        model = Cours
        fields = ('id', 'title', 'category')

Les vues

Maintenant, vous allez définir les vues qui vont permettre de gérer les requêtes et les réponses de l’API. Accédez à views.py et écrivez les lignes suivantes :

from rest_framework import generics
from .models import Cours
from .serializers import CoursSerializer
class CoursList(generics.ListCreateAPIView):
    queryset = Cours.objects.all()
    serializer_class = CoursSerializer
class CoursDetail(generics.RetrieveUpdateDestroyAPIView):
    queryset = Cours.objects.all()
    serializer_class = CoursSerializer

Les deux classes que vous venez de créer vont, d’une part, permettre de lister tous les cours et d’autre part, autoriser la récupération, la mise à jour et la suppression d’un cours en particulier.

Création des Endpoint

Afin que les utilisateurs puissent effectuer des requêtes sur ces deux classes, il faut créer les points de terminaisons correspondants. Pour cela, créez un fichier urls.py dans le dossier de votre projet, c’est-à-dire le dossier api et placez les codes suivants :

from django.urls import path
from api import views
urlpatterns = [
    path('', views.CoursList.as_view()),
    path('/', views.CoursDetail.as_view()),
]

Puis, dans le fichier urls.py du dossier initial du projet, c’est-à-dire celui déjà présent dans le dossier test_cours, vous allez mettre les codes suivants :

from django.contrib import admin
from django.urls import path, include
urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include('api.urls')),
]

Les deux Endpoint ci-dessus vont vous permettre d’effectuer des requêtes sur les deux vues précédemment créées.

Et voilà ! Vous avez créé votre tout premier API REST avec Django et Python. Vous pouvez maintenant passer aux tests et à la consommation de votre API ou celles des autres serveurs dans les prochaines sections que nous allons aborder.

Tester et consommer une API REST

Afin de tester une API REST que vous avez créée ou même ceux que les autres développeurs mettent à disposition, il existe plusieurs manières et outils.

Tout d’abord, vous devez connaitre les Endpoint que vous souhaitez utiliser. Pour cela, vous devez lire et comprendre les documentations associées aux APIs.

Une fois que vous avez en votre possession ces documentations, vous pouvez choisir parmi les moyens et outils qui existent. Vous avez le choix, par exemple, entre cURL, POSTMAN, Katalon Studio, REST Assured, etc.

Si l’on considère notre exemple précédent, sachez que Django possède un environnement de test que vous pouvez utiliser afin de voir les retours renvoyés par votre API.

Pour ce faire, vous devez activer le serveur de test comme suit :

python manage.py runserver

Une fois lancée, vous verrez un environnement dans lequel vous pouvez effectuer vos requêtes sur cette plateforme. Par exemple, pour créer un nouveau cours vous devez accéder au point de terminaison : 127.0.0.1 :8000/api/

Et si vous souhaitez accéder à un cours en particulier, il vous suffit de spécifier son id comme suit : 127.0.0.1/api/<id>, <id> est à remplacer par celui du cours à consulter ou à modifier. Une fois que la plateforme vous retourne le cours en question, il vous propose les boutons pour interagir avec ce dernier. Vous pouvez, par exemple effectuer des opérations de modification et de suppression.

Mais si vous souhaitez effectuer ce même test avec un autre outil, vous devez savoir manipuler l’outil en question. Par exemple, si vous utilisez cURL, pour interagir avec l’API que nous avons créée, les syntaxes sont les suivants :

• POST :

curl -i -H "Content-Type: application/json" -X POST
 -d '{"title":"Tuto Big Data", "category":"Big Data"}' http://127.0.0.1:8000/api

• GET :

curl -i http://127.0.0.1:8000/api/<id>

• PUT :

curl -i -H "Content-Type: application/json" -X PUT -d '{"title":"Cours Big Data"}' http://127.0.0.1/api/<id>

• DELETE :

curl -i -H "Content-Type: application/json" -X "DELETE"
http://127.0.0.1/api/<id>

Sécuriser une API REST

Puisque l’on parle d’échange d’informations, qui sont plus ou moins sensibles, il est primordial de sécuriser une API REST. En effet, nous ne sommes jamais à l’abri d’une personne malveillante souhaitant dérober des données que nous exposons, surtout à travers le web. Plusieurs manières sont envisageables et à mettre en place pour qu’une API soit le moins vulnérable possible :

• Utiliser le protocole HTTPS permet de chiffrer les échanges entre les deux parties, à savoir le client et le serveur ;
• Mettre en place un système d’authentification limite les personnes pouvant échanger avec l’API. Vous pouvez pour cela utiliser, par exemple, Json Web Token (JWT). JWT sert à identifier un utilisateur et à lui donner l’accès à l’API sur une durée déterminée. OAuth2 est également un excellent moyen d’authentifier un client pour lui prodiguer les autorisations nécessaires pour la consommation de l’API.
• Utiliser une clé d’API ainsi qu’une clé secrète permet de reconnaitre les applications accédant à l’API. Cela permet également de signer les requêtes effectuées par celles-ci.

Voilà, nous arrivons à la fin de cette chronique. Elle vous aidera à appréhender les API REST et les utiliser dans vos projets Big Data. En effet, comme vous l’aurez sans doute compris, les API REST sont utiles. En effet, ce sont eux qui sont principalement à l’origine de chaque collecte et analyse de données.

Pour aller plus loin et appréhender le fonctionnement du traitement des données massives, nous vous offrons également cette formation sur l’écosystème Hadoop :