Objectif(s)
  1. Faciliter les usages applicatifs
  2. Rendre un service orienté "confort d'utilisation" (ie. Performance)
Cible(s) 
Couverture


Principes

Ce pattern correspond à l'exposition d'un référentiel de ressources fonctionnelles (ie une source de données).
Il expose N services en entrée pour 1 source de données en sortie.
Il est sans état.

Les tables sont exposés sous la forme de ressources REST.

Les dépendances entre les ressources sont représentées sous la forme de liens et d'identifiants (liens HATEOS).


Séquence représentative de la médiation

actor Client

Client -> Médiation : une ressource
activate Médiation

database "Source de données"
Médiation -> "Source de données" : lecture
activate "Source de données"
"Source de données" --> Médiation
deactivate "Source de données"

Médiation --> Client : résultat
deactivate Médiation


Schéma EIP

Vision sans Middleware

Ce cas de figure est possible avec des solutions comme Oracle eBusiness. Ces solutions exposent des services applicatifs pures. Cela est contradictoire avec de très nombreux principes énoncés.

Le format d'exposition est TOUJOURS un format Natif... sur le protocole REST.


Vision avec Middleware

Cette vision est la plus intéressante. Le format et le protocole sont exposés avec 

HATEOS

Hypertext As The Engine Of Application State. Il s'agit d'inclure 

Les descriptions XML ou JSON sont agrémentées de méta-données de navigation.

La spécification recommandée est celle de SPRING.IO.


{
    "name": "Alice",
    "links": [ {
        "rel": "self",
        "href": "http://localhost:8080/customer/1"
    } ]
}