Qu'est-ce que RESTful Web Service?

Web vs Web Service
Qu'est - ce que RESTful Service ?
Utiliser la méthode HTTP explicitement
Être apatride (Stateless)
Exposer la structure de répertoire comme URI
Transférer XML, JSON ou tous les deux
Java RESTful Service pour les débutants

1. Web vs Web Service

Avant de répondre à la question de RESTful, je souhaite que vous reconnaissiez la différence entre le Web et le service Web.

Lorsque vous saisissez une URL dans le navigateur et vous obtenez un site web. Ceci est un contenu normal que vous pouvez lire et que son contenu est destiné aux utilisateurs finaux.

Alors que le Service Web est un concept plus large que celui du web ordinaire. Il fournit l'information brute et source de confusion pour la plupart des utilisateurs donc, il est utilisée par des applications. Ces applications vont analyser des données brutes avant de les renvoyer aux utilisateurs finaux.

Par exemple, lorsque vous entrez sur un certain site Web ABC pour voir les informations météorologiques et les informations sur les titres. Le site Web affichera l'information que vous voulez.

Afin d'obtenir les données météorologiques, l'application ABC doit obtenir les informations d'une certaine source. La source peut être un service Web qui fournit les données météorologiques à chaque région respectivement.

De même, afin d'obtenir les données sur les titres, l'application ABC doit contacter les services de fourniture des données. Les données seront traitées avant de vous retourner un site Web complet.

Les Services Web fournissent souvent les données brutes qui sont difficiles à comprendre pour la plupart des utilisateurs finaux courants et les Web Services sont souvent retournés en format XML ou JSON.

2. Qu'est - ce que RESTful Service ?

RESTful Web Service est un Web Service qui utilise la structure REST. REST a été largement utilisé, remplaçant les Web Services basés sur SOAP et WSDL. Les RESTful Web Services sont légers (lightweigh), faciles à étendre et à entretenir.

Le premier concept sur REST (Representational State Transfer) a été lancé en 2000 dans la thèse de doctorat deRoy Thomas Fielding (co-fondateur du protocole HTTP). Ses recherches détaillent les contraintes, les règles et la façon de fonctionner dans le système afin d'obtenir un système REST.

REST définit un ensemble de principes architecturaux par lesquels vous pouvez concevoir des services Web qui se concentrent sur les ressources d'un système, y compris la façon dont les états des ressources sont adressés et transférés via HTTP par un large éventail de clients écrits dans différentes langues. Mesuré par le nombre de services Web qui l'utilisent, REST s'est imposé au cours des dernières années seulement comme un modèle prédominant de conception de services Web. En fait, REST a eu un tel impact sur le Web qu'il a surtout déplacé la conception d'interfaces basées sur SOAP et WSDL parce que c'est un style considérablement plus simple à utiliser.

REST est un ensemble de règles qui vise à créer une application de Web Service selon les quatre règles de base ci-dessous :

Utiliser les méthodes HTTP explicitement.
Être apatride.
Exposer les URI de type structure de répertoires.
Transférer XML, JavaScript Object Notation (JSON), ou les deux.

Dans le mot RESTful, ful est suffixe (suffix) en anglais, comme help signifie l'aide , helpful est très utile.

3. Utiliser la méthode HTTP explicitement

REST donne une règle obligeant les programmeurs à spécifier leur but via la méthode HTTP. Les finalités comprennent normalement l'obtention, l'insertion, la mise à jour ou l'effacement des données. Dans le cas où vous souhaitez réaliser l'un des objectifs, vous devez prendre note des règles ci-dessous :

Pour créer une ressource sur le serveur, vous devez utiliser la méthode POST.
Pour accéder à une ressource, utilisez GET.
Pour modifier l'état d'une ressource ou pour la mettre à jour, utilisez PUT.
Pour annuler ou supprimer une ressource, utilisez DELETE.

Veuillez à noter que les règles ci-dessus ne sont pas obligatoires, en fait vous pouvez utiliser la méthode de GET pour demander les données, insérer, éditer ou supprimer les données sur le Serveur. Cependant, REST donne les règles mentionnées ci-dessus sur l'objectif que tout devient clair et compréhensible.

L'exemple ci-dessous est la façon dont vous utilisez GET pour ajouter plus de données sur le serveur (notez que cela est contraire aux règles de REST).

Utilisez GET pour demander d'ajouter un utilisateur nommé Robert.

GET /adduser?name=Robert HTTP/1.1

Utilisez GET pour demander le serveur à renommer le nom des utilisateurs de Robert à Smith.

GET /updateuser?name=Robert&amp;newname=Smith HTTP/1.1

Et maintenant, selon les règles de REST tout devient plus clair.

Envoyez la commande POST HTTP pour ajouter des données :

POST /users/Robert HTTP/1.1
Host: myserver
Content-Type: application/xml
<?xml version="1.0"?>
<user>
<name>Robert</name>
</user>

Envoyez une commande GET si vous souhaitez obtenir les données sur le système.

GET /users/Robert HTTP/1.1
Host: myserver
Accept: application/xml

Envoyez une commande PUT si vous souhaitez mettre à jour les données.

PUT /users/Robert HTTP/1.1
Host: myserver
Content-Type: application/xml
<?xml version="1.0"?>
<user>
 <name>Smith</name>
</user>

Envoyez la commande DELETE si vous voulez supprimer les données :

DELETE /users/Robert HTTP/1.1

4. Être apatride (Stateless)

Une caractéristique de REST est apatride, ce qui signifie qu'elle ne stocke pas les informations du client. Par exemple, vous venez d'envoyer une demande pour voir la page2 d'un document et vous souhaitez maintenant voir la page suivante (Page 3). REST ne stockera pas l'information qui vous a servi la page 2 précédemment. Cela signifie que REST ne gère pas Session.

L'image ci-dessous illustre une application de stockage d'état qui sait quel numéro de page les utilisateurs visualisent. Et les utilisateurs ont besoin uniquement de demander la "Next page" pour obtenir la page désirée.

Pour les conceptions sans état, le client doit envoyer une exigence claire, y compris le numéro de page

Les composants côté serveur sans état, par contre, sont moins compliqués à concevoir, à écrire et à distribuer sur des serveurs à répartition de charge équilibrée. Un service sans état non seulement fonctionne mieux, mais il transfère la plus grande partie de la responsabilité du maintien de l'état à l'application client. Dans un service Web RESTful, le serveur est responsable de générer des réponses et de fournir une interface qui permet au client de maintenir seul l'état de l'application.

5. Exposer la structure de répertoire comme URI

REST donne une structure permettant aux utilisateurs d'accéder à leurs ressources via les URL. Les ressources ici sont toutes les choses que vous pouvez nommer (vidéo, image, bulletin météorologique, ...)

Vous devez créer les REST services qui renvoient les ressources aux utilisateurs, respectivement.

Les adresses REST service vent être intuitives au point d'être faciles à deviner. Pensez à une URI comme une sorte d'interface d'auto-documentation qui nécessite peu ou pas d'explications ou de références pour qu'un développeur comprenne ce qu'elle indique et puisse en tirer des ressources connexes. cette fin, la structure d'une URI doit être simple, prévisible et facile à comprendre.

Voir l'URL ci-dessous, il fournit des informations météorologiques d'une région correspondant à une date donnée et il est facile à comprendre pour les utilisateurs.

http://myservice.com/weather/chicago/2016-09-27

http://myservice.com/weather/hanoi/2016-11-11

Quelques lignes directrices supplémentaires à prendre en compte lors de la réflexion sur la structure URI d'un service Web RESTful sont les suivantes :

Masquez les extensions de fichiers de la technologie de script côté serveur (.jsp,.php,.asp), s'il y en a, pour que vous puissiez porter sur autre chose sans modifier les URIs.
Gardez tout en minuscule.
Remplacez les espaces par des traits d'union ou des tirets de soulignement (l'un ou l'autre).
Évitez autant que possible les chaînes de requête.
Au lieu d'utiliser le code 404 Not Found si la requête URI est pour un chemin partiel, fournissez toujours une page ou une ressource par défaut comme réponse.

6. Transférer XML, JSON ou tous les deux

Lorsque le Client envoie une requête au service web, elle est souvent transmise en XML ou JSON et reçoit souvent des formulaires similaires.

Parfois, le Client peut également spécifier les types de données de retour qu'il souhaite (JSON ou XML, ...), ces désignations sont appelées le type de MINE, il est envoyé dans la section HEADER de la demande.
Voici les types communs de MINE utilisent normalement avec le REST service .

JSON	application/json
XML	application/xml
XHTML	application/xhtml+xml

Par exemple, le client envoie une demande pour obtenir des informations météorologiques et demande les données de retour au format XML.

GET /weather/chicago/2016-08-27 HTTP/1.1
Host: myservice.com
Accept: application/xml;q=0.5

Et les données reçues :

<weather>
    <date>2016-08-27</date>
    <location>Chicago</location>
    <info>Hot</info>"//
</weather>

Dans le cas où le client exige des données de retour au format JSON:

{
 "date": "2016-08-27",
 "location": "Chicago",
 "info": "Hot"
}