RESTful WebServices

Après cette quête tu sauras ce qui caractérise une API Rest et comment interagir avec elle

Objectifs

• Comprendre ce qu'est une API REST

• Connaître ses contraintes de conceptions

• Savoir communiquer avec une API REST

Une API ?

Une confusion existe entre un Web Service et une API. En effet, les limites entre les deux peuvent être difficiles à reconnaître et trop peu d'entre nous savent vraiment faire la différence.

WebService

La différence est cependant assez simple: un Web Service a pour but de faciliter des communications entre ordinateurs placés sur un réseau.

↗

Anatomie d'un Web Service

Article sur ce que sont les Web Services

guru99.com

API

Application Programming Interface forme l'acronyme API. Une API est donc une simple interface de programmation.

Qu'est-ce qu'une interface de programmation alors ?

C'est un interface qui permet d'échanger des données d'un point à un autre de plusieurs logiciels ou bases de données. C'est un ensemble de fonctionnalités permettant l'interaction entre plusieurs modules.

Une API n'est pas forcément Web ! Une API peut très bien être une bibliothèque écrite en C# qui permet d'enregistrer le nombre de réservations dans un hôtel à partir d'un logiciel en local. Une API est un moyen de communiquer, rien de plus !

↗

Qu'est-ce qu'une API ?

Description d'un API moderne communiquant avec le Cloud

redhat.com

REST

Il existe plusieurs formes d'architecture des API Web Services. L'architecture qui nous intéresse principalement est REST.

REST est l'acronyme de Representational State Transfer. C'est un style d'architecture permettant d'obtenir un couplage faible entre composants et une séparation claire des responsabilités.

Ce style d'architecture impose 5 contraintes à un Web Service. Si une API respecte ces 5 contraintes, on considère qu'elle est RESTful. Voici les 5 contraintes:

Architecture client-serveur

Le service ne répond qu'à la demande du client. Il n'initie jamais une connexion de son chef, il est toujours contacté par un client.

↗

Qu'est-ce que l'architecture Client/Serveur ?

Article Wikipédia décrivant ce qu'est l'architecture Client/Serveur

fr.wikipedia.org

Statelessness

Aucun contexte n'est stocké sur le serveur. Toutes les informations nécessaires à la réalisation d'une requête sont stipulées dans le corps ou l'en-tête de la requête HTTP. Aucun état particulier ne doit modifier le comportement du service. En clair, le fonctionnement d'un API REST ne dépend pas de l'état d'une ou plusieurs transactions de clients.

Je fais comment pour authentifier un client si le serveur ne peut pas sauvegarder de contexte ?

C'est simple, tu envoies toutes les informations d'authentification à chaque requête.

↗

La programmation stateless

Fil de discussion sur la programmation stateless

quora.com

Cachabilité

Une API Restful se veut performante et efficace. Utiliser des fonctionnalités de cache est très important pour les performances d'une application. Une API RESTful peut très bien implémenter un cache msi doit explicitement signaler à ses clients si des réponses sont mises en cache ou non.

↗

Un cache côté serveur

Article bref sur la mise en place d'un cache serveur pour une API REST

restcookbook.com

Système en couches

On est censé pouvoir ajouter ou enlever des instances d'un même web service sans que cela impacte l'application complète. Il doit être possible d'ajouter des _balanceurs de charge _ou des proxys sans altérer le fonctionnement des services ni-même le point d'entrée. En clair, un client n'a pas à savoir quel serveur dans le pool il sollicite pour ses requêtes.

↗

Contraintes d'architecture REST

Article sur les contraintes REST

restfulapi.net

Interfaces uniformes

Ceci est la partie la moins respectée des API REST sur l'Internet, mais aussi la plus importante pour qu'un Web Services soit considéré RESTful.

• Un service est censé pouvoir retourner les données qui lui sont demandées dans plusieurs formats: XML, HTML, JSON ...

• Un client doit envoyer toutes les informations nécessaires à l'identification d'une ressource

• Toutes les requêtes doivent être descriptives: surtout au niveau du format de son corps (XML, HTML, JSON ...)

• Le service doit mettre à disposition un moyen de découvrir toutes ses routes et possibilités. Ceci est généralement fait à l'aide d'une documentation robuste.

Respecter les contraintes de conception

Il est très difficile de respecter toutes les contraintes de conception d'une architecture REST. C'est pour cette raison que bon nombre de services sur le Web se présentant comme RESTful ne le sont pas, ou à moitié.

Voici un ensemble de ressources permettant de mieux comprendre comment concevoir des API REST.

↗

Comprendre les API REST

Tutoriel sur les API REST

mlsdev.com

↗

Principes de design d'une API

Recommandations de Jeff Bezos sur la construction des API REST chez Amazon

hackernoon.com

Communiquer avec une API

Lorsque les contraintes d'architecture REST sont bien appliquées, il doit être possible de communiquer dans plusieurs langages qu'elle autorise. Bien souvent, les API REST mettent à disposition deux langages de présentation de données pour communiquer: JSON et XML.

JSON

JSON (JavaScript Object Notation) est un langage de description très léger adapté à l'interprétation par des programmes informatiques. Il est aussi compréhensible par un humain, mais bien moins facile à lire qu'un XML. Comme son nom l'indique, il sert à représenter des objets transitants entre plusieurs points.

↗

Qu'est-ce que JSON ?

Tutoriel de la W3C sur ce qu'est JSON

w3schools.com

XML

XML est un langage de balisage permettant de représenter des données. Il est beaucoup plus simple de lire et comprendre un XML qu'un JSON, spécialement lorsque les objets sont compliqués. De plus, XML est extensible et est décliné pour plein d'utiliser. Il peut être imposé à un XML de respecter un schéma à partir d'un .XSD.

↗

Qu'est-ce que XML ?

Tutoriel de la W3C sur ce qu'est JSON

w3schools.com

Un blog bien codé

Depuis longtemps, tu aimerais pouvoir faire un blog sur un de tes sujets préférés. Le problème est que la concurrence est rude et qu'il va falloir que tu t'inspires des autres avant de pouvoir écrire tes propres articles.

Une aubaine pour toi: certaines parties du Web ont justement été conçues pour pouvoir récupérer des données facilement avec une interface compréhensible.

Rappel sur les méthodes HTTP

Une API REST pouvant mettre à disposition des fonctions d'édition et de récupération du même type de donnée, elle utilise bien souvent la sémantique des méthodes HTTP pour réaliser le taf.

Ainsi, sur une même ressource /user/1, où 1 est l'id de l'utilisateur, plusieurs méthodes doivent être mises à disposition:

• GET pour récupérer les informations sur l'utilisateur

• PATCH pour mettre à jour un ou plusieurs champs de l'utilisateur

• DELETE pour supprimer la ressources

• Et toutes les autres requêtes voulues et imaginables ...

↗

Liste des méthodes HTTP

Documentation Mozilla sur les requêtes HTTP

developer.mozilla.org

Challenge

Un bloggueur

Maintenant que tu deviens bloggueur confirmé, il faut que tu saches aggréger tes flux d'informations et t'inspirer des autres !

Durant ce challenge, il va falloir que tu prouves que tu sais manipuler une API REST et ses différentes possibilités.

Tu vas utiliser cette API qui stocke des informations sur des blogs.

Critères de validation

• Fournis un exécutable communiquant avec l'API JSONPlaceHolder réalisant toutes les opérations suivantes:

• L'utilisateur doit pouvoir spécifier un utilisateur (son id)

• Récupère tous les posts de l'utilisateur

• Récupère tous les commentaires de tous les posts associés à l'utilisateur

• Récupère toutes les photos de tous les albums de l'utilisateur

• Le format de présentation de l'application est libre: console ou GUI