Skip to content

SoapVsRest.md

Latest commit

 

History

History
475 lines (342 loc) · 35.5 KB

SoapVsRest.md

File metadata and controls

475 lines (342 loc) · 35.5 KB

Introduction

Concepts de programmations

Dans la programmation moderne, il existe deux concepts cruciaux :

  • Le modèle client-serveur
  • Les Interfaces de Programmation d'Application (API).

Qu'es ce qu'un modèle Client-serveur

Le concept de modèle client-serveur, répond d'une architecture qui va répartir les tâches d'une application entre deux partie.

  • Premièrement un serveur. Qui serviras de fournisseur de ressources ou de service.
  • Deuxièmement un client. Qui auras pour objectif d'effectuer des requête pour avoir accès aux ressources et services du serveur.

Pour Exemple si nous prenons le fonctionnement du site et de l'application Le Bon Coin. Sur une recherche d'article.

  • Le Client seras donc, soit le site web, soit l'application et auras pour rôle de demander à un serveur, une liste d'annonce. En fonction de différent paramètre de recherche. Puis d'afficher les résultat
  • Le serveur qu'an à lui, seras le programme qui reçoit les requête de l'application ou du site web. Puis qui filtreras l'ensemble des annonce enregistrer en base de donnée, en fonction des différent paramètre de recherche.

En termes simples, le client est l'application sollicitant des informations ou réalisant des actions, tandis que le serveur est le programme qui répond en envoyant des informations ou en exécutant des actions en fonction des demandes du client.

La plupart des applications modernes fonctionnent selon le modèle client-serveur, où les clients demandent des ressources ou des services que les serveurs exécutent. Cette communication entre les deux parties s'effectue généralement par le biais d'une API, une interface de programmation d'application.

Qu'est ce qu'une API

Une API ce définie par un ensemble de règles, de protocoles et de définitions qui permettent à des logiciels distincts de communiquer entre eux. Elle définit les méthodes et les formats de données standardisés pour la transmission d'informations entre différentes applications, facilitant ainsi l'intégration et l'interaction entre celles-ci.

Une API agit comme un pont, permettant à une application (ou un service) d'accéder aux fonctionnalités ou aux données d'une autre application de manière structurée et sécurisée. Elle spécifie les points d'entrée autorisés pour interagir avec un logiciel particulier, détaillant comment les requêtes doivent être formulées et comment les réponses seront retournées.

Les API sont omniprésentes dans le développement logiciel actuel, avec la majorité des applications utilisant le modèle client-serveur alimenté par des communications API. Il est donc essentiel pour les développeurs de bien comprendre ces concepts.

Elles peuvent prendre différentes formes, notamment les API web (comme REST et GraphQL), les API de bibliothèques logicielles, les API matérielles, etc. Une API bien conçue simplifie le développement en fournissant une interface claire et documentée, réduisant ainsi la complexité de l'intégration entre différentes applications.

En résumé, une API est un ensemble de règles standardisées permettant à des logiciels distincts de se connecter, de communiquer et d'échanger des informations de manière cohérente et sécurisée.

Avec ces concepts en tête, plongeons dans les détails du fonctionnement des API SOAP et REST.

Comment fonctionne une API SOAP

SOAP (Simple Object Access Protocol) est un protocole de messagerie déployé pour la transmission de données structurées entre des systèmes Internet distincts. Fondé sur XML, SOAP est reconnu comme l'un des premiers protocoles de service Web, ayant émergé en 1998 grâce à Microsoft. Cette technologie a vu le jour en tant que successeur du Common Object Request Broker Architecture (CORBA) et du Distributed Component Object Model (DCOM).

L'objectif initial de SOAP était de créer un moyen indépendant de la plate-forme permettant l'échange de données entre des systèmes hétérogènes sur Internet. Pour atteindre cette ambition, SOAP a été normalisé par le World Wide Web Consortium (W3C) en 2003.

Ainsi, SOAP représente un jalon dans le domaine des protocoles de service Web, en fournissant une méthode standardisée et basée sur XML pour la communication entre systèmes, avec une origine marquée par sa conception par Microsoft en réponse aux besoins d'interopérabilité sur Internet.

Caractéristiques principales de SOAP

  • Basé sur XML : SOAP utilise XML comme format de message, ce qui permet la structuration des données échangées entre les systèmes.

  • Indépendant de la plate-forme : SOAP est conçu pour fonctionner avec n'importe quel langage de programmation ou plate-forme prenant en charge XML et pouvant envoyer et recevoir des messages HTTP.

  • Protocole de messagerie : SOAP est un protocole de messagerie qui définit comment les messages doivent être structurés, envoyés et traités entre les applications.

  • Extensibilité : SOAP offre une flexibilité importante grâce à sa capacité à être étendu pour répondre à des besoins spécifiques, ce qui le rend adapté à un large éventail de scénarios d'utilisation.

  • Standardisé : SOAP a été normalisé par le World Wide Web Consortium (W3C), ce qui garantit une spécification claire et reconnue pour son utilisation dans le développement web.

  • Interopérabilité : En étant conçu pour permettre l'interopérabilité entre différentes plateformes, SOAP facilite la communication entre des systèmes distribués fonctionnant sur des technologies variées.

  • Supporte différents protocoles de transport : SOAP n'est pas lié à un protocole de transport spécifique et peut être utilisé avec différents protocoles tels que HTTP, SMTP, etc., ce qui le rend adaptable à divers environnements réseau.

Inconvénients

  • Complexité : La structure XML de SOAP peut rendre les messages complexes, nécessitant davantage de bande passante et de ressources de traitement par rapport à des formats plus légers.

  • Surcharge de données : En raison de sa nature basée sur XML, SOAP peut entraîner une surcharge de données, ce qui le rend moins efficace pour les applications où la taille des messages et la performance sont des préoccupations majeures.

  • Rigidité : SOAP est souvent considéré comme plus rigide en termes de définition des messages, ce qui peut rendre l'adaptation à des changements dans les structures de données plus difficile.

  • Difficulté de mise en œuvre : La mise en œuvre de SOAP peut être plus complexe par rapport à d'autres protocoles plus légers tels que REST, en raison de ses spécifications détaillées.

  • Moins adapté aux ressources limitées : Dans des environnements avec des ressources limitées, comme sur des appareils mobiles, la surcharge liée à l'utilisation de SOAP peut être un inconvénient significatif.

  • Moins convivial pour les humains : En raison de sa syntaxe basée sur XML, la lisibilité des messages SOAP par les humains est souvent moins intuitive par rapport à d'autres formats plus légers.

  • Moins adapté aux architectures orientées ressources : Les architectures orientées ressources, souvent privilégiées dans le style REST, peuvent rendre SOAP moins approprié pour certaines applications.

  • Performances : SOAP peut être plus lent que d'autres protocoles API en raison de sa nature de messagerie.

Le meilleur pour

  • Transmettre des données sensibles : SOAP prend en charge plusieurs normes de sécurité, ce qui en fait un choix sécurisé pour la transmission de données sensibles.

  • Prendre en charge des structures de données complexes : SOAP prend en charge des structures de données complexes, ce qui en fait un bon choix pour la transmission et l'échange de données entre différents systèmes.

Secteur d'implémentations

Les API SOAP ont été largement utilisées au début des services Web et sont encore utilisées aujourd'hui dans plusieurs domaines bien que REST soit devenus plus populaires ces dernières années. SOAP est utilisé en particulier dans des environnements où des normes strictes, la sécurité et la gestion des transactions sont cruciales. Voici quelques domaines où SOAP est fréquemment employé :

  • Services financiers : SOAP est encore largement utilisé dans les applications de santé, en particulier dans les dossiers de santé électroniques (DSE) et les échanges d'informations sur la santé (HIE). En effet, SOAP fournit un moyen sécurisé et fiable de transmettre des informations sensibles sur les patients entre différents systèmes.

  • Santé : Les applications et les systèmes de santé, en raison de la nécessité de respecter des réglementations strictes en matière de sécurité des données et de confidentialité des patients, utilisent fréquemment SOAP.

  • Entreprises et applications d'entreprise : SOAP est toujours utilisé dans les applications d'entreprise, telles que les systèmes de gestion de la relation client (CRM) et de planification des ressources d'entreprise (ERP), car il fournit un moyen standardisé et fiable d'échanger des données entre différents systèmes.

  • Télécommunications : Dans l'industrie des télécommunications, SOAP est parfois préféré pour sa capacité à gérer des transactions complexes et à assurer la fiabilité des communications.

  • Applications gouvernementales : Les projets gouvernementaux, en raison de leurs exigences élevées en matière de sécurité, de normes strictes et de gestion des transactions, peuvent utiliser SOAP pour les communications entre systèmes.

  • Intégration de systèmes d'entreprise : Lorsque des systèmes hétérogènes doivent être intégrés et que des fonctionnalités avancées telles que la gestion des transactions sont nécessaires, SOAP peut être un choix judicieux.

  • Industrie manufacturière : Dans des environnements où des systèmes complexes doivent interagir tout en respectant des normes spécifiques, SOAP peut être utilisé pour assurer une communication fiable et sécurisée.

  • Systèmes existants : de nombreux systèmes et applications plus anciens utilisent encore des API SOAP, et leur migration vers des technologies plus récentes peut s'avérer coûteuse et longue.

Il est important de noter que bien que SOAP soit toujours utilisé dans ces domaines, d'autres protocoles, tels que REST, gagnent également en popularité, en particulier dans des contextes plus légers et axés sur le web. Le choix entre SOAP et d'autres protocoles dépend souvent des exigences spécifiques du projet et des préférences de l'organisation.

Fonctionnement XML

Comme mentionné, les API SOAP utilisent XML comme format principal de transmission de données, expliquons donc comment fonctionne XML.

XML signifie Extensible Markup Language. Il s'agit d'un langage de balisage qui permet aux utilisateurs de créer des balises et des attributs personnalisés pour décrire la structure et le contenu des données.

XML utilise un ensemble de règles pour coder les documents dans un format à la fois lisible par l'homme et par la machine. Ceci est réalisé en utilisant des balises pour définir les éléments d'un document, similaire au HTML.

Voici un exemple du fonctionnement de XML :

  • Structure de Balisage : XML utilise une structure de balisage, semblable à HTML, pour définir les données. Les éléments XML sont encadrés par des balises. Une balise ouvrante <tag> marque le début d'un élément, et une balise fermante </tag> indique la fin de cet élément. Par exemple :
<person>
    <name>John Doe</name>
    <age>30</age>
</person>
  • Hiérarchie : Les éléments XML peuvent être imbriqués les uns dans les autres, créant ainsi une structure hiérarchique. Cela permet de représenter des relations complexes entre les données. Par exemple : 
    <book>
  <title>Le Seigneur des Anneaux</title>
  <author>
      <name>J.R.R. Tolkien</name>
      <birth_year>1892</birth_year>
  </author>
```
  • Attributs : En plus des balises, XML permet l'utilisation d'attributs pour fournir des informations supplémentaires sur les éléments. Les attributs sont généralement placés à l'intérieur de la balise ouvrante. Par exemple :
<car make="Toyota" model="Camry" year="2022"/>
  • Document XML : Un document XML est un ensemble de données structurées conformément à la syntaxe XML. Il commence généralement par une déclaration XML pour spécifier la version d'XML utilisée. Par exemple :
<?xml version="1.0" encoding="UTF-8"?>
<root>
    <!-- Les éléments et les données vont ici -->
</root>

  • Commentaires : XML permet l'ajout de commentaires dans le document en utilisant la syntaxe <!-- commentaire -->.

  • Validation : Les documents XML peuvent être validés par rapport à une DTD (Document Type Definition) ou un schéma XML. Cela garantit que le document suit une structure prédéfinie et répond aux exigences spécifiées.

  • Interchangeabilité : XML est indépendant des plateformes et des langages de programmation, ce qui signifie que les données peuvent être échangées entre différents systèmes de manière cohérente.

  • Traitement : Les données XML peuvent être traitées à l'aide de différentes technologies, telles que XPath pour la navigation, XSLT pour la transformation, et DOM (Document Object Model) ou SAX (Simple API for XML) pour la manipulation programmable des données.

En résumé, XML fonctionne en fournissant une structure de balisage extensible qui permet de représenter des données de manière hiérarchique et lisible, facilitant ainsi l'échange et le stockage d'informations entre différentes applications et systèmes. Cependant, son utilisation a diminué ces dernières années avec la montée en puissance de formats plus modernes tels que JSON et YAML, plus légers et plus faciles à utiliser pour de nombreuses applications

Utilisation d'une API SOAP

L'utilisation d'une API SOAP avec JavaScript implique généralement l'envoi de requêtes SOAP à l'aide de bibliothèques appropriées pour manipuler les messages XML et communiquer avec le service Web. Un exemple courant est l'utilisation de la bibliothèque axios pour effectuer des appels SOAP. Notez que certaines des étapes peuvent varier en fonction du service Web spécifique que vous utilisez. Voici un exemple simple :

Installation de la bibliothèque axios :

npm install axios
  • Création de la requête SOAP :
const axios = require('axios');
const xml2js = require('xml2js');

// Fonction pour créer une requête SOAP
function createSOAPRequest() {
   const soapRequest = `<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" \     xmlns:web="http://www.example.com/webservice">
   <soapenv:Header/>
   	<soapenv:Body>
   		<web:GetData>
   			<web:Param1>value1</web:Param1>
   			<web:Param2>value2</web:Param2>
   		</web:GetData>
   	</soapenv:Body>
   </soapenv:Envelope>`;
   return soapRequest;
}

- **Envoi de la requête SOAP avec `axios` :**
```js
async function sendSOAPRequest() {
   const url = 'https://www.example.com/soap-endpoint';

   const headers = {
       'Content-Type': 'text/xml;charset=UTF-8',
       'SOAPAction': 'http://www.example.com/webservice/GetData'
   };

   const soapRequest = createSOAPRequest();

   try {
       const response = await axios.post(url, soapRequest, { headers });
       const responseData = response.data;

       const parser = new xml2js.Parser({ explicitArray: false });
       parser.parseString(responseData, (err, result) => {
           console.log('Réponse en objet JavaScript :', result);
       });
   } catch (error) {
       console.error('Erreur lors de l\'appel SOAP :', error.message);
   }
}

sendSOAPRequest();

Supposons que vous envoyez une requête SOAP pour obtenir des informations sur un utilisateur à un service Web. Voici à quoi la réponse SOAP générique pourrait ressembler :

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:web="http://www.example.com/webservice">
   <soapenv:Header/>
   <soapenv:Body>
      <web:GetUserDataResponse>
         <web:User>
            <web:UserID>123</web:UserID>
            <web:FirstName>John</web:FirstName>
            <web:LastName>Doe</web:LastName>
            <web:Email>john.doe@example.com</web:Email>
         </web:User>
      </web:GetUserDataResponse>
   </soapenv:Body>
</soapenv:Envelope>

Dans cet exemple générique, la réponse SOAP est encapsulée dans une enveloppe SOAP avec un corps contenant les données demandées. Dans ce cas, les informations sur l'utilisateur sont incluses dans l'élément GetUserDataResponse. Vous devrez adapter cette structure en fonction de la spécification de l'API ou du service Web auquel vous accédez.

Pour accéder aux valeurs de la réponse XML, vous pouvez utiliser l'API DOMParser pour analyser la réponse dans un objet document XML, puis utiliser les méthodes de traversée DOM pour parcourir le document et extraire les valeurs.

Par exemple, le code suivant extrait la valeur de Valueélément de l'objet document XML :

const parser = new DOMParser();
const xmlDoc = parser.parseFromString(xml, 'text/xml');
const userID = xmlDoc.getElementsByTagName('UserID')[0].childNodes[0].nodeValue;
const firstName = xmlDoc.getElementsByTagName('FirstName')[0].childNodes[0].nodeValue;
const lastName = xmlDoc.getElementsByTagName('LastName')[0].childNodes[0].nodeValue;
const email = xmlDoc.getElementsByTagName('Email')[0].childNodes[0].nodeValue;
console.log(userID); // output: 123
console.log(firstName); // output: John
console.log(lastName); // output: Doe
console.log(email); // output: john.doe@example.com

Dans l'ensemble, les réponses SOAP ont tendance à être plus détaillées et complexes que les réponses des API REST, en raison de leur utilisation du XML et du format d'enveloppe. Mais ce format offre un moyen standardisé d’échange d’informations qui peut être utile dans certains secteurs et cas d’utilisation.

Comment fonctionne une API REST

Representational State Transfer (REST) est un style architectural largement utilisé pour créer des services Web et des API.

Roy Fielding a introduit REST en 2000 dans sa thèse doctorale intitulée "Architectural Styles and the Design of Network-based Software Architectures". Roy Fielding, également un contributeur majeur du protocole HTTP, a défini REST comme un style architectural fondé sur les principes du Web.

Les API RESTfull sont spécifiquement conçues pour être simples, adaptables et évolutives. Elles trouvent fréquemment leur utilisation dans des applications Web, mobiles, ainsi que dans des architectures telles que l'Internet des objets (IoT) et les micro services. L'objectif principal de REST est de faciliter la communication entre les composants distribués sur le Web en adoptant des principes clés pour assurer la simplicité, la flexibilité et la scalabilité des services.

Caractéristiques principales de REST

REST offre plusieurs avantages qui contribuent à sa popularité dans le développement d'API et de services web. Voici quelques-uns des principaux avantages de REST :

  • Sans état : les API REST sont sans état, ce qui signifie que chaque requête contient toutes les informations nécessaires à son traitement. Cela facilite la mise à l'échelle de l'API et améliore les performances en réduisant le besoin de stocker et de gérer les données de session sur le serveur.

  • Basées sur les ressources : les API REST sont basées sur les ressources, ce qui signifie que chaque ressource est identifiée par un URI (Uniform Resource Identifier) ​​unique et est accessible à l'aide de méthodes HTTP standard telles que GET, POST, PUT et DELETE.

  • Interface uniforme : les API REST ont une interface uniforme qui permet aux clients d'interagir avec les ressources à l'aide d'un ensemble standardisé de méthodes et de formats de réponse. Cela permet aux développeurs de créer et de maintenir plus facilement des API, et aux clients de les utiliser.

  • Mise en cache : les API REST peuvent être mises en cache, ce qui signifie que les réponses peuvent être mises en cache pour améliorer les performances et réduire le trafic réseau

  • Système en couches : les API REST sont conçues pour être superposées, ce qui signifie que des intermédiaires tels que des proxys et des passerelles peuvent être ajoutés entre le client et le serveur sans affecter l'ensemble du système.

  • Évolutivité : REST est conçu pour être évolutif. La séparation des préoccupations entre le client et le serveur, ainsi que l'utilisation d'un système sans état, permettent une évolutivité horizontale aisée. Les serveurs peuvent être mis à l'échelle pour gérer une charge croissante.

  • Flexibilité : Les clients peuvent demander et manipuler des ressources de différentes manières en utilisant les méthodes HTTP standard (GET, POST, PUT, DELETE). Cela offre une flexibilité considérable dans la manière dont les ressources sont gérées et manipulées.

  • Interopérabilité : En utilisant des standards du web tels que HTTP et en se basant sur des formats de données courants comme JSON et XML, REST favorise l'interopérabilité entre différentes plateformes et langages de programmation.

  • Performance : En évitant la surcharge liée au maintien de l'état des sessions côté serveur, REST peut offrir de bonnes performances, en particulier dans des environnements à grande échelle.

  • Visibilité : Les API RESTful sont souvent auto-descriptives, ce qui signifie que les détails de la ressource et de ses opérations peuvent être découverts facilement par les développeurs en consultant la documentation ou en explorant l'API.

  • Réutilisabilité des composants : Les ressources peuvent être manipulées de manière uniforme à l'aide des méthodes standard, favorisant ainsi la réutilisation des composants logiciels.

  • Facilité de test : Étant donné que REST utilise des méthodes HTTP standard, il est facile à tester à l'aide d'outils standard tels que les clients HTTP.

  • Adaptabilité : REST peut être utilisé dans une variété de contextes, que ce soit pour des applications web, mobiles, l'Internet des objets (IoT), ou des architectures de micro services.

  • Large prise en charge : les API REST sont largement prises en charge par les outils et frameworks de développement, ce qui facilite leur intégration dans les systèmes existants

En combinant ces avantages, REST offre une approche souple et efficace pour la création d'API et de services web, adaptée à divers scénarios de développement.

Inconvénients

Bien que REST présente de nombreux avantages, il existe également certains inconvénients ou limitations à prendre en compte selon les contextes d'utilisation. Voici quelques-uns des inconvénients potentiels de REST :

  • Manque de normes : REST offre des principes directeurs, mais il n'y a pas de normes strictes, ce qui peut conduire à des variations dans la mise en œuvre entre différentes API RESTful.

  • Complexité des opérations complexes : La manipulation de transactions complexes, comme les transactions atomiques sur plusieurs ressources, peut être difficile à réaliser de manière propre et cohérente dans le cadre de REST.

  • Sécurité : Bien que REST offre certaines options pour sécuriser les communications (par exemple, HTTPS), il ne définit pas explicitement des normes de sécurité, laissant cette responsabilité aux développeurs. Les API REST peuvent donc être vulnérables aux attaques de sécurité telles que les scripts intersites (XSS) et la falsification de requêtes intersites (CSRF) si elles ne sont pas mises en œuvre correctement.

  • Problèmes de performances liés à la surcharge de données : Dans certaines situations, la représentation complète d'une ressource peut entraîner une surcharge de données, surtout si toutes les données ne sont pas nécessaires pour une opération particulière.

  • Manque de contrôle sur la gestion des erreurs : La gestion des erreurs peut être limitée, en particulier lorsqu'il s'agit de retours d'erreurs standardisés, ce qui peut rendre le débogage complexe.

  • Manque de découverte automatique : Bien que RESTful soit auto-descriptif dans une certaine mesure, il ne fournit pas toujours des mécanismes automatiques de découverte de ressources ou d'opérations.

  • Manipulation de l'état : Le côté sans état de REST peut rendre complexe la gestion de l'état des sessions dans certaines applications.

  • Imposition de conventions : Certains développeurs peuvent considérer les conventions de REST comme contraignantes, surtout lorsqu'ils ont besoin de flexibilité pour concevoir des API plus personnalisées.

  • Performance dans des environnements avec de nombreuses petites requêtes : Dans des scénarios où de nombreuses requêtes individuelles doivent être effectuées, la surcharge des requêtes HTTP peut entraîner des problèmes de performances.

  • Complexité de la documentation : Bien que l'auto-descriptivité soit un avantage, la documentation complète peut encore être nécessaire pour comprendre pleinement la structure et les fonctionnalités d'une API REST.

Il est important de noter que la pertinence de ces inconvénients dépend du contexte spécifique de l'application et des besoins du projet. Certains de ces inconvénients peuvent être atténués par des bonnes pratiques de conception et des extensions spécifiques de l'API. Dans certains cas, d'autres architectures, comme GraphQL, peuvent être envisagées comme alternatives selon les exigences spécifiques du projet.

Fonctionnement JSON

JSON (JavaScript Object Notation) est un format de données léger, lisible par l'homme et facile à écrire et à comprendre. Il est souvent utilisé pour échanger des données entre un serveur et un client, ainsi que pour stocker des configurations ou des données structurées dans des fichiers. Voici comment fonctionne JSON :

  1. Format de données basé sur le texte : JSON utilise une syntaxe basée sur le texte, ce qui signifie que les données sont représentées sous forme de texte lisible par l'homme. Cela facilite la lecture, l'écriture et la compréhension des données.

  2. Structure de paire clé-valeur : Les données JSON sont organisées en paires clé-valeur. Chaque paire clé-valeur associe une clé (une chaîne de caractères) à une valeur. La valeur peut être un nombre, une chaîne, un objet JSON, un tableau, un booléen, ou null.

    Exemple d'objet JSON avec des paires clé-valeur :

{
  "nom": "John Doe",
  "age": 30,
  "ville": "Paris",
  "estEtudiant": false
}

  • Objets JSON : Les objets JSON sont des ensembles non ordonnés de paires clé-valeur, entourés par des accolades {}. Chaque paire clé-valeur est séparée par une virgule.

  • Tableaux JSON : Les tableaux JSON sont des listes ordonnées de valeurs, entourées par des crochets []. Les éléments du tableau peuvent être de n'importe quel type de données JSON.

    Exemple de tableau JSON :

["pomme", "orange", "banane"]

  • Types de données : JSON prend en charge plusieurs types de données :

    • Nombre : Représenté comme un nombre (entier ou décimal).
    • Chaîne de caractères : Représentée entre guillemets doubles ("...").
    • Booléen : true ou false.
    • Objet : Une collection non ordonnée de paires clé-valeur.
    • Tableau : Une liste ordonnée de valeurs.
    • null : Représente une valeur nulle.

  • Hiérarchie et Nesting : Les objets et les tableaux peuvent être imbriqués pour créer une structure hiérarchique et complexe. Par exemple, un objet peut contenir une paire clé-valeur dont la valeur est un autre objet ou un tableau.

    Exemple avec un objet JSON imbriqué :

{
  "personne": {
    "nom": "Alice",
    "âge": 25,
    "adresses": ["Paris", "New York"]
  }
}

  • Sérialisation et Désérialisation : La sérialisation consiste à convertir des données depuis une structure de données (comme un objet JavaScript) en une chaîne JSON. La désérialisation est le processus inverse, convertissant une chaîne JSON en une structure de données.

    En JavaScript, la sérialisation d'un objet en JSON se fait avec JSON.stringify() :

const objetJS = { nom: "John", age: 30 };
const chaineJSON = JSON.stringify(objetJS);

Et la désérialisation avec JSON.parse() :

const chaineJSON = '{"nom": "John", "age": 30}';
const objetJS = JSON.parse(chaineJSON);

JSON offre une simplicité et une lisibilité qui le rendent populaire pour la transmission de données entre les applications et les services web. Il est également largement utilisé dans le développement web et mobile.

Utilisation d'une API REST

Voici un exemple illustrant comment effectuer une simple requête GET à une API REST à partir d'une application frontale JavaScript et comment accéder aux valeurs contenues dans la réponse:

// URL de l'API à utiliser
const apiUrl = 'https://jsonplaceholder.typicode.com/todos/1';

// Utilisation de la fonction fetch pour envoyer une requête GET
fetch(apiUrl)
  .then(response => {
    // Vérification de la réponse HTTP
    if (!response.ok) {
      throw new Error(`Erreur HTTP! Statut : ${response.status}`);
    }
    // Conversion de la réponse en format JSON
    return response.json();
  })
  .then(data => {
    // Traitement des données reçues
    console.log('Données de l\'API:', data);
  })
  .catch(error => {
    // Gestion des erreurs
    console.error('Erreur lors de la requête API:', error.message);
  });

Voici ce à quoi de réponse REST générique pourrait ressembler :

{
  "userId": 1,
  "id": 1,
  "title": "delectus aut autem",
  "completed": false
}

Dans cet exemple, une requête GET est envoyée à une API fictive (JSONPlaceholder) pour récupérer des informations sur une tâche spécifique. La réponse est traitée et affichée dans la console. La gestion des erreurs est également prise en compte pour assurer une expérience robuste.

La réponse type est une représentation simplifiée des données que l'API pourrait renvoyer. Les données peuvent varier en fonction de l'API réelle utilisée.

à noté que le format JSON permet une interaction simple ainsi si serais possible de récupéré les valeurs du résultat de la sorte :

console.log(data.userId); // output: 1
console.log(data.id); // output: 1
console.log(data.title); // output: "delectus aut autem"
console.log(data.completed); // output: false

Il est aussi possible d'utiliser la notation par parenthèse comme ceci :

console.log(data['userId']); // output: 1
console.log(data['id']); // output: 1
console.log(data['title']); // output: "delectus aut autem"
console.log(data['completed']); // output: false

Ici, datafait référence à l'objet JavaScript qui contient les données de réponse.

Les réponses de l'API REST sont généralement plus simples et plus légères que les réponses SOAP, et elles sont souvent formatées en JSON. L'utilisation de formats standard permet aux clients d'analyser plus facilement la réponse et d'extraire les données pertinentes.

De plus, les API REST utilisent souvent des codes d'état HTTP standard pour indiquer le succès ou l'échec d'une requête, ce qui peut simplifier la gestion des erreurs côté client.

Dans l'ensemble, les API REST constituent une approche populaire et largement utilisée pour créer des API Web en raison de leur simplicité, de leur flexibilité et de leur facilité d'utilisation.

Versus entre les API REST et SOAP

Pour fini voici un comparatif entre une API REST et une API SOAP, ce dernier couvre différents aspects, y compris la simplicité, la flexibilité, la performance, la sécurité, la complexité, etc.

  • Format des données :

    • REST : Utilise souvent JSON comme format de données, privilégiant sa légèreté et sa facilité de manipulation dans les langages de programmation.
    • SOAP : Utilise exclusivement XML, qui est plus verbeux que JSON mais offre une structure rigide et une sérialisation/désérialisation standardisée.

  • Style d'architecture :

    • REST : Repose sur les principes du Web, notamment l'utilisation de ressources identifiées par des URIs, un modèle sans état, et l'utilisation d'opérations standard HTTP (GET, POST, PUT, DELETE).
    • SOAP : Suit un modèle client-serveur plus procédural, où le client envoie des requêtes spécifiques au serveur pour des opérations définies.

  • Protocole de communication :

    • REST : Utilise généralement HTTP, mais peut également fonctionner sur d'autres protocoles comme HTTPS ou même MQTT pour l'Internet des objets (IoT).
    • SOAP : Utilise souvent HTTP et SMTP, mais peut être implémenté sur d'autres protocoles personnalisés.

  • Flexibilité :

    • REST : Conçu pour être simple, léger et flexible, adapté aux architectures modernes comme les applications web, mobiles et les microservices.
    • SOAP : Plus orienté entreprise, adapté aux environnements nécessitant une structure et des normes strictes.
    • Interopérabilité :
      • REST : Favorise l'interopérabilité grâce à l'utilisation de standards du web et de formats de données communs tels que JSON.
      • SOAP : Peut nécessiter des efforts supplémentaires pour garantir une interopérabilité complète en raison de la complexité de la norme.

  • Performance :

    • REST : Souvent plus performant en raison de l'utilisation de formats de données légers et de l'absence d'état côté serveur.
    • SOAP : Peut avoir une surcharge de performance due à l'utilisation d'XML, qui est plus verbeux que JSON, et à la gestion des états de session.

  • Simplicité :

    • REST : Facile à comprendre et à mettre en œuvre, particulièrement pour des cas d'utilisation légers et centrés sur le web.
    • SOAP : Plus complexe, nécessite la création de descriptions de service (WSDL) et peut impliquer des opérations complexes telles que la gestion des états de session.

  • Sécurité :

    • REST : La sécurité repose souvent sur HTTPS, et des mécanismes standards tels que les jetons d'accès peuvent être utilisés pour renforcer la sécurité.
    • SOAP : Propose des normes de sécurité spécifiques (WS-Security) pour garantir la confidentialité et l'intégrité des données, mais cela peut ajouter de la complexité.

  • Documentation :

    • REST : Souvent auto-descriptif grâce à l'utilisation d'URIs significatifs et de formats de données communs, mais une documentation explicite est généralement nécessaire.
    • SOAP : Exige généralement des descriptions de service (WSDL) pour documenter les opérations disponibles et les structures de données.

  • Utilisation :

    • REST : Convient généralement aux applications web, mobiles, aux architectures de microservices, et aux API modernes.
    • SOAP : Souvent utilisé dans des environnements d'entreprise où des normes strictes et des opérations complexes sont nécessaires, par exemple, dans les services financiers et de santé.

Le choix entre REST et SOAP dépend des besoins spécifiques du projet, des préférences de l'organisation, et des contraintes particulières, telles que des exigences de sécurité strictes ou des normes industrielles spécifiques.