Le document traite de l'architecture orientée services (SOA), de ses

principes, avantages, technologies associées (comme SOAP et REST) et

d'une introduction à GraphQL. Voici un résumé détaillé :

1. Introduction à SOA

 Définition : SOA est une approche de conception logicielle qui

structure les applications en services réutilisables et indépendants.

 Caractéristiques :

o Interopérabilité : Interaction entre services malgré des

technologies différentes.

o Encapsulation : Les services cachent leur complexité interne.

o Réutilisabilité : Les services peuvent être utilisés dans divers

contextes.

 Exemples :

o Intégration de cartes Google dans une page web.

o Ajout automatique de tweets récents sur un profil.

2. Fonctionnement de SOA

 Décomposition : Les processus métier sont divisés en services

spécifiques (ex. facturation, gestion des utilisateurs).

 Communication : Via des messages standard (HTTP, XML, JSON)

utilisant SOAP ou REST.

 Couplage faible : Les services peuvent évoluer indépendamment.

3. Technologies SOA

 SOAP : Protocole pour échanger des messages structurés basé sur

XML.

 WSDL : Langage pour décrire les interfaces des services SOAP.

 REST : Style architectural simplifiant les interactions grâce à des

contraintes comme :

o Séparation client-serveur.

o État indépendant entre les requêtes.

 o Caches pour optimiser les performances.

4. Avantages de SOA

 Interopérabilité : Fonctionne sur des plateformes différentes (Java,

.NET).

 Réutilisation des services : Réduction de duplication du code.

 Modularité : Facilite l’ajout et la suppression de composants.

5. Comparaison SOAP et REST

 SOAP :

o Basé sur XML uniquement.

o Utilise des schémas pour une communication stricte.

 REST :

o Supporte JSON, XML.

o Orienté sur des opérations CRUD (GET, POST, PUT, DELETE).

6. Introduction à GraphQL

 GraphQL : Créé par Facebook, il permet de définir précisément les

données souhaitées dans une requête unique, réduisant ainsi la
surcharge réseau.

 Avantages :

o Flexibilité accrue pour récupérer des données spécifiques.

o Évolutivité sans casser les clients existants.

7. Pratiques conseillées pour API

 Bonnes pratiques REST :

o Utiliser des noms d'URI clairs et descriptifs.

o Implémenter les verbes HTTP de manière cohérente.

o Gérer les erreurs avec des codes HTTP appropriés (ex. 404
pour "Non trouvé").
  GraphQL :

o Définir des schémas clairs (ex. types Product).

o Utiliser des fragments pour réutiliser des parties de requêtes.

Exercices proposés

 Création d'un schéma GraphQL pour un produit avec des requêtes

pour :

o Récupérer tous les produits.

o Filtrer par catégorie.

o Obtenir un produit spécifique.

Voici une synthèse détaillée de l'intégralité du contenu du cours basé sur
l'architecture orientée services (SOA), en incluant toutes les parties
abordées :

1. Introduction à SOA

 Définition : Une approche pour concevoir des systèmes logiciels en

les structurant en services réutilisables et indépendants,
favorisant l'interopérabilité, la modularité et la réutilisation.

 Objectif : Diviser des systèmes complexes en composants

autonomes appelés services, interconnectés via des interfaces
standardisées (API).

2. Définition d’un service

 Unité logicielle autonome :

o Effectue une tâche spécifique.

o Accès via une interface publique.

 Caractéristiques :

o Interopérabilité : Fonctionne avec d'autres technologies.

o Encapsulation : Cache les détails internes du service.

o Réutilisabilité : Adapté à divers contextes.

 Exemples pratiques :

o Intégration de Google Maps sur une page web.

o Ajout automatique de tweets sur une page personnelle.

3. Fonctionnement de SOA

 Décomposition des processus métiers : Services spécifiques tels

que facturation ou gestion des utilisateurs.

 Exposition des services :

o Via des interfaces définies (API, services web).

o Communication via des messages formatés (XML, JSON).

 Couplage faible : Les services peuvent évoluer indépendamment,

minimisant les impacts sur le système global.
4. Caractéristiques clés de SOA

 Couplage faible : Minimisation des dépendances entre services.

 Interopérabilité : Indépendance des plateformes, assurée par des

standards comme HTTP, SOAP, REST.

 Réutilisation : Services conçus pour être réutilisés dans divers

projets.

 Granularité : Services modulables, allant de tâches simples (ex.

validation d’adresse e-mail) à complexes (ex. traitement de
commandes).

 Indépendance des plateformes : Intégration entre technologies

variées (Java, .NET).

5. Standards associés à SOA

 XML : Format pour structurer les données.

 SOAP (Simple Object Access Protocol) :

o Protocole standard pour échanger des messages.

o Basé sur XML, souvent utilisé avec HTTP ou SMTP.

 WSDL (Web Services Description Language) :

o Définit les API de services.

o Décrit les modèles, interfaces, et points d’accès.

6. REST (Representational State Transfer)

 Style architectural défini par Roy Fielding (2000).

 Contraintes clés :

1. Client-Serveur : Séparation des rôles.

2. Sans état (Stateless) : Chaque requête contient toutes les

informations nécessaires.

3. Cacheable : Amélioration des performances via le cache.

4. Système en couches : Modularité par séparation en couches

logiques.
 5. Interface uniforme : Identité claire des ressources par URI.

6. Code à la demande (facultatif) : Exécution dynamique de

code par le client.

 Principales méthodes HTTP :

o GET : Récupération de ressources.

o POST : Création de ressources.

o PUT : Mise à jour ou création si l’URI est défini.

o DELETE : Suppression de ressources.

 Bonnes pratiques REST :

o Utiliser des URI clairs et courts.

o Fournir des réponses au format JSON ou XML.

o Gérer les erreurs avec des codes HTTP appropriés.

7. Comparaison SOAP vs REST

 SOAP :

o Utilise uniquement XML.

o Nécessite des outils complexes.

o Plus sécurisé, idéal pour les environnements exigeants (ex.

banques).

 REST :

o Plus simple, basé sur HTTP.

o Supporte plusieurs formats (JSON, XML).

o Moins contraignant et adapté aux applications modernes.

8. Introduction à GraphQL

 Langage de requête pour les API, créé par Facebook (2012).

 Avantages :

o Requêtes spécifiques aux besoins du client.

o Réduction de la surcharge réseau (moins d'appels API

nécessaires).
 o Adapté aux applications complexes nécessitant une grande
flexibilité.

 Schémas GraphQL :

o Décrivent les types de données, les relations et les opérations

disponibles.

9. Types d’opérations GraphQL

 Requêtes : Récupération des données.

o Syntaxe hiérarchique pour structurer les requêtes.

 Mutations : Modification des données.

o Similaires aux requêtes mais modifient les ressources (ajouter,

mettre à jour, supprimer).

 Subscriptions : Notifications en temps réel lorsque des données

changent.

10. Bonnes pratiques pour GraphQL

 Utiliser des fragments pour réutiliser des portions de requêtes.

 Optimiser les requêtes pour éviter les doublons ou les données

inutiles.

 Fournir des descriptions claires des schémas pour faciliter leur

utilisation.

11. Exemples et exercices pratiques

1. Créer un schéma GraphQL simple pour des produits, avec les

champs :

o id, name, description, price, category.

2. Requêtes à implémenter :

o Récupérer tous les produits.

o Filtrer par catégorie.

o Obtenir un produit spécifique par son nom.

Exercice de cour

Solution : Exercice sur GraphQL

1. Définition du schéma GraphQL

Un schéma GraphQL est utilisé pour définir les types de données et les
requêtes disponibles.

type Product {

id: ID! # Identifiant unique du produit

name: String! # Nom du produit

description: String # Description du produit

price: Float! # Prix du produit

category: String! # Catégorie du produit

type Query {

getAllProducts: [Product!]! # Récupérer tous les produits

getProductsByCategory(category: String!): [Product!]! # Récupérer les

produits par catégorie

getProductByName(name: String!): Product # Récupérer un

produit spécifique par son nom

}
2. Première requête : Récupérer tous les produits

query {

getAllProducts {

id

name

description

price

category

Résultat attendu (exemple) :

"id": "1",

"name": "Laptop",

"description": "A high-performance laptop",

"price": 1500.99,

"category": "Electronics"

},

"id": "2",

"name": "Desk Chair",

"description": "Ergonomic office chair",

"price": 250.50,

"category": "Furniture"

}
]

3. Deuxième requête : Récupérer les produits dans une catégorie

spécifique

query {

getProductsByCategory(category: "Electronics") {

id

name

description

price

category

Résultat attendu (exemple) :

"id": "1",

"name": "Laptop",

"description": "A high-performance laptop",

"price": 1500.99,

"category": "Electronics"
 },

"id": "3",

"name": "Smartphone",

"description": "Latest model with advanced features",

"price": 999.99,

"category": "Electronics"

4. Troisième requête : Récupérer un produit spécifique

query {

getProductByName(name: "Laptop") {

id

name

description

price

category

Résultat attendu (exemple) :

{

"id": "1",

"name": "Laptop",

"description": "A high-performance laptop",

"price": 1500.99,

"category": "Electronics"

Correction de TD

Solutions des exercices sur les API REST

Exercice 1 : Codes de statut HTTP

1. Signification des codes de statut HTTP

1. 200 OK : La requête a réussi et a renvoyé le résultat attendu.

2. 201 Created : Une ressource a été créée avec succès.

3. 204 No Content : La requête a été traitée avec succès, mais

aucune donnée n'est renvoyée.

4. 400 Bad Request : La requête est invalide (erreur côté client, ex.
syntaxe incorrecte).

5. 404 Not Found : La ressource demandée est introuvable.

6. 500 Internal Server Error : Une erreur s'est produite côté serveur.

2. Scénarios concrets pour chaque code

1. 200 OK : Récupérer la liste des livres d'une bibliothèque (GET

/books).

2. 201 Created : Ajouter un nouveau livre à la bibliothèque (POST

/books).

3. 204 No Content : Supprimer un livre de la bibliothèque (DELETE

/books/{id}).

4. 400 Bad Request : Envoyer une requête pour ajouter un livre sans
fournir toutes les informations nécessaires (par ex. le titre).

5. 404 Not Found : Rechercher un livre par ID inexistant (GET

/books/{id}).

6. 500 Internal Server Error : Erreur interne lors de la récupération

des données.

Exercice 2 : Création d’une API REST fictive

1. Endpoints pour une application de gestion de livres

 Endpoin Méthode
Fonctionnalité Codes de statut possibles
t HTTP

Récupérer la liste des

/books GET 200 OK
livres

Récupérer un livre /books/

GET 200 OK, 404 Not Found
spécifique {id}

Ajouter un nouveau 201 Created, 400 Bad

/books POST
livre Request

Mettre à jour un livre /books/ 200 OK, 400 Bad Request,

PUT
existant {id} 404 Not Found

/books/ 204 No Content, 404 Not

Supprimer un livre DELETE
{id} Found

Exercice 3 : Manipulation des ressources

1. Gestion des amis d'un utilisateur

1. Ajouter un ami :

o Requête : POST /users/{userId}/friends

o Corps : { "friendId": 123 }

o Codes de statut : 201 Created, 400 Bad Request, 404 Not

Found.

2. Voir la liste d’amis :

o Requête : GET /users/{userId}/friends

o Codes de statut : 200 OK, 404 Not Found.

3. Supprimer un ami :

o Requête : DELETE /users/{userId}/friends/{friendId}

o Codes de statut : 204 No Content, 404 Not Found.

Exercice 4 : Comparaison des méthodes PUT et PATCH

1. Différence entre PUT et PATCH

 PUT : Remplace l'ensemble de la ressource par les nouvelles

données.
 o Exemple : Mettre à jour toutes les informations d'un utilisateur.

 PATCH : Modifie uniquement certains champs de la ressource.

o Exemple : Mettre à jour l'adresse e-mail d'un utilisateur.

2. Exemples de requêtes

1. PUT :

o Requête : PUT /users/1

o Corps :

o {

o "name": "Alice",

o "email": "alice@example.com",

o "age": 30

o }

o Utilisation : Lorsque toutes les données de l'utilisateur

doivent être remplacées.

2. PATCH :

o Requête : PATCH /users/1

o Corps :

o {

o "email": "alice.new@example.com"

o }

o Utilisation : Lorsque seule l'adresse e-mail doit être mise à

jour.
Exercice 5 : Conception d’une API REST pour un système de
réservation de salles

1. Endpoints nécessaires

Codes de
Fonctionnalit Méthod Paramètre
Endpoint statut
é e HTTP s requis
possibles

Récupérer
toutes les /rooms GET Aucun 200 OK
salles

Récupérer les
200 OK, 404
détails d’une /rooms/{roomId} GET roomId
Not Found
salle

200 OK, 400

Vérifier la /rooms/{roomId}/ roomId,
GET Bad
disponibilité availability date, time
Request

201
roomId, Created,
Réserver une /rooms/{roomId}/
POST date, time, 400 Bad
salle reserve
userId Request,
409 Conflict

204 No
roomId,
Annuler une /rooms/{roomId}/ Content,
DELETE reservationI
réservation reserve/{id} 404 Not
d
Found
2. Exemple de structure de réponse JSON

1. Récupérer toutes les salles :

2. [

3. {

4. "id": 1,

5. "name": "Salle de réunion A",

6. "capacity": 10

7. },

8. {

9. "id": 2,

10. "name": "Salle de conférence",

11. "capacity": 50

12. }

13. ]

14. Réserver une salle :

o Réponse (succès) :

o {

o "reservationId": 12345,

o "roomId": 1,

o "date": "2024-12-01",

o "time": "10:00-12:00",

o "userId": 789

o }

o Codes de statut associés :

 201 Created : Réservation réussie.

 400 Bad Request : Paramètres invalides.

 409 Conflict : La salle est déjà réservée.