Qu'est-ce que RESTful Web Service?

View more categories:

1- Web vs Web Service

Avant de répondre à la question de  RESTful, je souhaite que vous reconnaissiez la différence entre le service Web et le service Web.
Lorsque vous tapez une URL dans votre 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 service web, c'est un concept plus large que le concept web ordinaire, il fournit l'information brute et source de confusion pour la plupart des utilisateurs donc, elle est utilisée par l'application. Ces applications de traitement des données brutes avant de revenir pour les utilisateurs finaux.

Par exemple, lorsque vous entrez un certain site Web ABC pour voir les informations météorologiques et les informations sur les valeurs mobilières. Le site Web affichera les informations souhaitées.


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, pour obtenir les données sur les valeurs mobilières, l'application ABC doit contacter les services de fournitures de ces données. Les données seront traitées avant de vous renvoyer un site Web complet.

Les Services Web fournissent souvent les données brutes difficiles à comprendre pour la plupart des utilisateurs communs et les services Web sont souvent retournés au format XML ou JSON.

2- Qu'est - ce que RESTful Service ?

RESTful Web Service est les  Web Service sont écrits basés sur la structure  REST. REST a été largement utilisé, en 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 de Roy Thomas Fielding (co-fondateur du protocole  HTTP). Dans sa thèse d'introduction assez détaillée des contraintes et des règles ainsi que la façon de mettre en œuvre le système pour obtenir un système  REST.
REST définit les règles de l'architecture vous concevoir des Web Services, en mettant l'accent sur les ressources du système, y compris l'état des ressources sont formatés et transmis via  HTTP et est écrite en plusieurs langues. Si on calcule en fonction du nombre de services de réseau à utiliser,  REST a émergé ces dernières années comme un modèle de conception de services prévaut. En fait,  REST a fait un grand impact et presque remplacé  SOAP, car il est plus simple et  WSDL et plus facile à utiliser que beaucoup.
REST est un ensemble de règles pour créer une application de  Web Service qu'elle respecte les quatres de règles de base ci-dessous:
  1. Utilisez la méthode HTTP explicitement
  2. Apatride
  3. Afficher la structure de dossiers comme les URL
  4. Transfert JavaScript Object Notation (JSON), XML ou tous les deux.
Dans le mot  RESTful, ful est suffixe (suffix) en anglais, comme help signifie l'aide , helpful est très utile.

3- Utilisez la méthode HTTP explicitement

REST définit une règle qui oblige les programmeurs à définir clairement ses intentions par le biais de méthode  HTTP. Habituellement, l'intention qui inclut récupérée des données, insertion de données, mise à jour de données ou effacer les données. Donc, lorsque vous souhaitez effectuer l'une des intentions ci-dessus s'il vous plaît notez les règles suivantes :
  • 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.
Notez 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&newname=Smith HTTP/1.1
Et maintenant, selon les règles de  REST tout devient plus clair.
Envoyer 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>
Envoyer 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
Envoyer 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>
Envoyer 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
Ainsi, le composant serveur apatrides moins complexe à concevoir, écrire et affecté par l'équilibrage de la charge du serveur. Les services non étatiques non seulement mieux fonctionnent, il s'installe aussi la plupart du rôle de l'état de la demande est maintenue dans le client. Dans un service Web  RESTful, le serveur est chargé de donner des commentaires et fournit un moyen de permettre au client de maintenir l'état de l'application elle-même

5- Donner 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 doivent être intuitifs au point où ils sont faciles à deviner. Pensez à un URI comme une sorte d'interface autodidacte qui nécessite peu ou pas d'explication ou de référence pour un développeur pour comprendre ce qu'il indique et dériver des ressources connexes. À cette fin, la structure d'un URI devrait ê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 règles supplémentaires de noter tout en parlant de la structure de l'adresse de RESTful Web service est
  • Cacher l'extension de la queue du document de l'original dans le serveur (.jsp, .php, .asp), si c'est le cas, alors vous pouvez cacher certaines choses sans changer les Urls
  • Gardez tout en minuscule.
  • Remplacer les espaces par des tirets ou des soulignés (l'un ou l'autre).
  • Évitez les chaînes de requêtes autant que vous le pouvez. 
  • Au lieu d'utiliser le code (404 Not Found) lorsque vous demandez une adresse pour une partie du chemin, toujours fournir une page par défaut ou d'une ressource comme une réponse.

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

Lorsque le Client envoie une demande au service Web, il est souvent transmis 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 .
MIME-Type Content-Type
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 nécessite des 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"
}

7- Java RESTful Service pour les débutants

  • TODO Link!
  • TODO Link!

View more categories: