# RĂšgles de liaison JSON (JSON Binding Rules)

# Préface

Cette section contient des informations sur la maniùre d’utiliser ce document.

# Conventions Utilisées dans ce Document

Les conventions suivantes sont utilisĂ©es dans ce document pour identifier les types d’informations spĂ©cifiĂ©s.

Type d’information Convention Exemple
ÉlĂ©ments de l’API, tels que ressources Gras /authorization
Variables Italique entre accolades {ID}
Termes du glossaire Italique Ă  la premiĂšre occurrence ; dĂ©fini dans Glossaire Le but de l’API est de permettre des transactions financiĂšres interopĂ©rables entre un Payeur (un payeur de fonds Ă©lectroniques dans une transaction de paiement) situĂ© dans un FSP (une entitĂ© qui fournit un service financier numĂ©rique Ă  un utilisateur final) et un BĂ©nĂ©ficiaire (un destinataire de fonds Ă©lectroniques dans une opĂ©ration de paiement) situĂ© dans un autre FSP.
Documents de rĂ©fĂ©rence Italique Les informations utilisateur ne doivent, en gĂ©nĂ©ral, pas ĂȘtre utilisĂ©es par les dĂ©ploiements API ; les mesures de sĂ©curitĂ© dĂ©taillĂ©es dans Signature API et Chiffrement API doivent ĂȘtre utilisĂ©es Ă  la place.

# Informations sur la Version du Document

Version Date Description des modifications
1.0 2018-03-13 Version initiale

# Introduction

L’objectif de ce document est d’exprimer le modĂšle de donnĂ©es utilisĂ© par l’API ouverte pour l’interopĂ©rabilitĂ© des Fournisseurs de Services Financiers (FSP) (ci-aprĂšs appelĂ©e « l’API ») sous la forme de rĂšgles de liaison JSON Schema, ainsi que les rĂšgles de validation de leurs instances correspondantes.

Ce document complĂšte et dĂ©veloppe l’information fournie dans Open API for FSP Interoperability Specification. Les contenus de la spĂ©cification sont listĂ©s dans Vue d’ensemble de l’API FSPIOP.

Les types utilisĂ©s dans l’API PDP relĂšvent principalement de trois catĂ©gories :

  • Types de donnĂ©es et formats de base utilisĂ©s

  • Types d’élĂ©ments

  • Types complexes

Les diffĂ©rents types utilisĂ©s dans DĂ©finition de l’API, ModĂšle de DonnĂ©es et SpĂ©cification Open API, ainsi que les rĂšgles de transformation JSON auxquelles leurs instances doivent se conformer, sont identifiĂ©s dans les sections suivantes.


# SpĂ©cification Open API pour l’interopĂ©rabilitĂ© des FSP

La spĂ©cification Open API pour l’interopĂ©rabilitĂ© des FSP inclut les documents suivants.

# Documents Logiques

# Documents de Liaison REST Asynchrone

# Intégrité des Données, Confidentialité et Non-répudiation

# Documents Généraux


# Mots-clés et Utilisation

Les mots-clĂ©s utilisĂ©s dans les SchĂ©mas JSON et les rĂšgles sont dĂ©rivĂ©s de la SpĂ©cification JSON Schema1 (opens new window). Les types de mots-clĂ©s employĂ©s sont identifiĂ©s dans les sections Mots-clĂ©s de validation, Mots-clĂ©s de mĂ©tadonnĂ©es et Instance-et-$ref. Comme expliquĂ© plus en dĂ©tail plus loin, certains de ces mots-clĂ©s spĂ©cifient des paramĂštres de validation tandis que d’autres sont plus descriptifs, comme les mĂ©tadonnĂ©es. La description suivante prĂ©cise, par exemple, si un champ DOIT2 (opens new window) ĂȘtre prĂ©sent dans la dĂ©finition ou s’il est associĂ© Ă  un certain type de donnĂ©es.

# Mots-clés de validation

Cette section3 (opens new window) fournit des descriptions des mots-clĂ©s utilisĂ©s pour la validation dans la DĂ©finition de l’API. Les mots-clĂ©s de validation dans un schĂ©ma imposent des exigences pour la validation rĂ©ussie d’une instance.

# maxLength

La valeur de ce mot-clĂ© DOIT ĂȘtre un entier non nĂ©gatif. Une instance chaĂźne est valide vis-Ă -vis de ce mot-clĂ© si sa longueur est infĂ©rieure ou Ă©gale Ă  la valeur de ce dernier. La longueur d’une instance chaĂźne est le nombre de ses caractĂšres selon la RFC 7159 [RFC7159].

# minLength

La valeur de ce mot-clĂ© DOIT ĂȘtre un entier non nĂ©gatif. Une instance chaĂźne est valide pour ce mot-clĂ© si sa longueur est supĂ©rieure ou Ă©gale Ă  la valeur de ce dernier. Omettre ce mot-clĂ© a le mĂȘme effet que de lui assigner la valeur 0.

# pattern

La valeur de ce mot-clĂ© DOIT ĂȘtre une chaĂźne de caractĂšres. Cette chaĂźne DEVRAIT ĂȘtre une expression rĂ©guliĂšre valide selon la syntaxe ECMA 262. Une instance chaĂźne est valide si l’expression rĂ©guliĂšre correspond avec succĂšs. Rappel : les expressions rĂ©guliĂšres ne sont pas implicitement ancrĂ©es.

# items

La valeur de items DOIT ĂȘtre un schĂ©ma JSON valide ou un tableau de schĂ©mas valides. Ce mot-clĂ© dĂ©termine comment les instances enfants sont validĂ©es pour les tableaux ; il ne valide pas directement l’instance elle-mĂȘme. Si items est un schĂ©ma, la validation rĂ©ussit si tous les Ă©lĂ©ments du tableau valident contre ce schĂ©ma. Si items est un tableau de schĂ©mas, la validation rĂ©ussit si chaque Ă©lĂ©ment valide contre le schĂ©ma Ă  la mĂȘme position. Omettre ce mot-clĂ© a le mĂȘme effet que de spĂ©cifier un schĂ©ma vide.

# maxItems

La valeur de ce mot-clĂ© DOIT ĂȘtre un entier non nĂ©gatif. Une instance de tableau est valide contre maxItems si sa taille est infĂ©rieure ou Ă©gale Ă  cette valeur.

# minItems

La valeur de ce mot-clĂ© DOIT ĂȘtre un entier non nĂ©gatif. Une instance de tableau est valide contre minItems si sa taille est supĂ©rieure ou Ă©gale Ă  cette valeur. Omettre ce mot-clĂ© a le mĂȘme effet que la valeur 0.

# required

La valeur de ce mot-clĂ© DOIT ĂȘtre un tableau. Les Ă©lĂ©ments DOIVENT ĂȘtre des chaĂźnes de caractĂšres uniques. Une instance objet est valide contre ce mot-clĂ© si chaque Ă©lĂ©ment du tableau est le nom d’une propriĂ©tĂ© prĂ©sente dans l’instance. Omettre ce mot-clĂ© revient Ă  avoir un tableau vide.

# properties

La valeur de properties DOIT ĂȘtre un objet. Chaque valeur de cet objet DOIT ĂȘtre un schĂ©ma JSON valide. Ce mot-clĂ© dĂ©finit comment les enfants sont validĂ©s pour les objets ; il ne valide pas l’instance elle-mĂȘme. La validation rĂ©ussit si, pour chaque nom commun entre l’instance et le schĂ©ma, l’instance enfant valide contre le schĂ©ma correspondant. Omettre ce mot-clĂ© revient Ă  un objet vide.

# enum

La valeur de ce mot-clĂ© DOIT ĂȘtre un tableau. Il DEVRAIT inclure au moins un Ă©lĂ©ment. Les Ă©lĂ©ments DEVRAIENT ĂȘtre uniques. Une instance valide contre ce mot-clĂ© si sa valeur est Ă©gale Ă  un des Ă©lĂ©ments du tableau. Les Ă©lĂ©ments peuvent ĂȘtre de toute valeur, y compris null.

# type

La valeur de ce mot-clĂ© DOIT ĂȘtre une chaĂźne ou un tableau. Si c’est un tableau, les Ă©lĂ©ments DOIVENT ĂȘtre des chaĂźnes uniques. Les chaĂźnes DOIVENT ĂȘtre un des six types primitifs (null, boolean, object, array, number, ou string), ou integer pour les entiers. Une instance valide si et seulement si elle fait partie de l’un des ensembles listĂ©s pour ce mot-clĂ©.

Cette spĂ©cification utilise le type string pour tous les types de base et d’élĂ©ments, mais applique des restrictions avec des expressions rĂ©guliĂšres via patterns. Les types complexes sont des objets et contiennent des propriĂ©tĂ©s de type Ă©lĂ©ment ou objet Ă  leur tour. Les types array servent Ă  spĂ©cifier des listes, actuellement seulement utilisĂ©es dans des types complexes.

# Mots-clés de métadonnées

Cette section dĂ©crit les champs utilisĂ©s dans les dĂ©finitions JSON des types. Elle prĂ©cise si un champ DOIT ĂȘtre prĂ©sent dans la dĂ©finition et s’il est associĂ© Ă  un type de donnĂ©es principal.

# definitions

La valeur de ce mot-clĂ© DOIT ĂȘtre un objet. Chaque membre DOIT ĂȘtre un schĂ©ma JSON valide. Ce mot-clĂ© ne joue pas de rĂŽle dans la validation. Il offre un emplacement standardisĂ© pour inclure des schĂ©mas JSON dans un schĂ©ma plus gĂ©nĂ©ral.

# title et description

La valeur des deux mots-clĂ©s DOIT ĂȘtre une chaĂźne. Ces deux mots-clĂ©s peuvent fournir Ă  une interface utilisateur des informations sur les donnĂ©es produites. Un titre sera de prĂ©fĂ©rence court, tandis qu’une description expliquera le but de l’instance dĂ©crite.

# Instance et $ref

Deux mots-clĂ©s, Instance et $ref sont utilisĂ©s dans les dĂ©finitions JSON Schema ou les rĂšgles de transformation dans ce document, dĂ©crits dans Instance et RĂ©fĂ©rences de SchĂ©ma avec $ref. Instance n’est pas utilisĂ© dans la SpĂ©cification Open API ; ce terme sert Ă  dĂ©crire des rĂšgles de validation et de transformation dans ce document. $ref contient une URI comme rĂ©fĂ©rence Ă  d’autres types ; il est utilisĂ© dans la SpĂ©cification.

# Instance

JSON Schema interprÚte les documents selon un modÚle de données. Une valeur JSON interprétée selon ce modÚle est appelée une instance4 (opens new window). Une instance a un des six types primitifs, et une plage de valeurs selon le type :

  • null : Production JSON null.

  • boolean : Valeur true ou false de la production JSON.

  • object : Ensemble non ordonnĂ© de propriĂ©tĂ©s associant une chaĂźne Ă  une instance (production object).

  • array : Liste ordonnĂ©e d’instances (production array JSON).

  • number : Nombre dĂ©cimal en prĂ©cision arbitraire, base-10, production number.

  • string : Suite de points de code Unicode (production string JSON).

Les espaces et le formatage sont hors du pĂ©rimĂštre du JSON Schema. Comme un objet ne peut pas avoir deux propriĂ©tĂ©s avec la mĂȘme clĂ©, le comportement d’un document JSON essayant d’avoir deux propriĂ©tĂ©s de mĂȘme nom est indĂ©fini.

# Références de schéma avec le mot-clé $ref

Le mot-clĂ© $ref5 (opens new window) sert Ă  rĂ©fĂ©rencer un schĂ©ma et permet de valider des structures rĂ©cursives via l’auto-rĂ©fĂ©rence. Un objet schĂ©ma avec une propriĂ©tĂ© $ref DOIT ĂȘtre interprĂ©tĂ© comme rĂ©fĂ©rence. La valeur de $ref DOIT ĂȘtre une rĂ©fĂ©rence URI. Concernant l’URI de base courante, elle identifie l’URI d’un schĂ©ma Ă  utiliser. Toutes autres propriĂ©tĂ©s d’un objet $ref DOIVENT ĂȘtre ignorĂ©es.

L’URI n’est pas un localisateur rĂ©seau, seulement un identifiant. Un schĂ©ma n’a pas besoin d’ĂȘtre tĂ©lĂ©chargeable Ă  partir de l’adresse si c’est une URL rĂ©seau, et les implĂ©mentations ne DOIVENT PAS effectuer d’opĂ©ration rĂ©seau quand elles rencontrent une URI rĂ©seau. Un schĂ©ma NE DOIT PAS tourner en boucle infinie sur un schĂ©ma. Par exemple, si deux schĂ©mas "#alice" et "#bob" ont une propriĂ©tĂ© "allOf" qui rĂ©fĂ©rence l’autre, un validateur naĂŻf pourrait passer en boucle. Les schĂ©mas NE DOIVENT PAS utiliser de telles boucles rĂ©cursives ; le comportement est indĂ©fini.

On l’utilise avec la syntaxe "$ref" et il est mappĂ© Ă  une dĂ©finition existante. La syntaxe de la valeur _$ref_, #/definitions/, indique que le type rĂ©fĂ©rencĂ© vient de la section DĂ©finitions de la SpĂ©cification Open API (typiquement, les sections sont Paths, Definitions, Responses et Parameters). Un exemple se trouve en Liste 26, oĂč les types pour les propriĂ©tĂ©s authentication et authenticationValue sont fournis par des rĂ©fĂ©rences vers les types AuthenticationType et AuthenticationValue.

# Définitions JSON et exemples

Les dĂ©finitions JSON et exemples sont fournis aprĂšs la plupart des sections dĂ©finissant les rĂšgles de transformation, si pertinent. Ils sont fournis au format JSON, tirĂ©s de la version JSON de la SpĂ©cification Open API. Les expressions rĂ©guliĂšres dans les exemples peuvent avoir de petites diffĂ©rences (parfois un ‘\’ supplĂ©mentaire) par rapport Ă  celles des rĂšgles car les exemples sont issus de la version JSON alors que les rĂšgles viennent de la spĂ©cification standard Open API (Swagger). Ils sont fournis dans la section concernĂ©e sous forme de Liste numĂ©rotĂ©e. Par exemple, Liste 1 fournit la version JSON de la dĂ©finition du type de donnĂ©es Amount.

Pour chaque type de donnĂ©es, une description du schĂ©ma JSON extrait de la SpĂ©cification Open API et (si pertinent) un exemple pour ce type sont fournis. AprĂšs la description du schĂ©ma, viennent les rĂšgles de transformation qui s’appliquent Ă  une instance de ce type particulier.


# Types d’élĂ©ments et types de base

Cette section contient les dĂ©finitions et rĂšgles de transformation pour les formats de base et les types Ă©lĂ©ments utilisĂ©s par l’API comme spĂ©cifiĂ© dans API Definition et API Data Model. Ces dĂ©finitions sont basiques dans le contexte de la spĂ©cification API, mais pas dans la spĂ©cification technique Open API. Souvent, ces types de donnĂ©es de base sont dĂ©rivĂ©s des types de base supportĂ©s par Open API, comme le type string.

# Type de données Amount

Cette section fournit la définition JSON Schema pour le type de données Amount. Liste 1 fournit le schéma JSON pour le type Amount.

  • Paire clĂ©-valeur JSON avec Nom "title" et Valeur "Amount"

  • Paire clĂ©-valeur JSON avec Nom "type" et Valeur "string"

  • Paire clĂ©-valeur JSON avec Nom "pattern" et Valeur "^([0]|([1-9][0-9]{0,17}))([.][0-9]{0,3}[1-9])?$"

  • Paire clĂ©-valeur JSON avec Nom "description" et Valeur "Le type de donnĂ©es Amount de l’API est une chaĂźne JSON dans un format canonique, restreint par une expression rĂ©guliĂšre pour des raisons d’interopĂ©rabilitĂ©. Ce format n’autorise pas de zĂ©ros en fin, mais permet un montant sans unitĂ© mineure de devise. Seules quatre dĂ©cimales au plus dans l’unitĂ© mineure ; aucune valeur nĂ©gative n’est permise. Pas plus de 18 chiffres dans l’unitĂ© majeure."

# Liste 1
"Amount": {
    "title": "Amount", 
    "type": "string", 
    "pattern":
    "^([0]|([1-9][0-9]{0,17}))([.][0-9]{0,3}[1-9])?$",
    "maxLength": 32, 
    "description": "Le type de donnĂ©es Amount de l’API est une chaĂźne JSON dans un format canonique, restreint par une expression rĂ©guliĂšre pour des raisons d’interopĂ©rabilitĂ©." 
} 

Liste 1 -- JSON Schema pour le type Amount

Les rĂšgles de transformation pour une instance du type Amount sont les suivantes :

  • Une instance du type Amount DOIT ĂȘtre de type string.

  • L’instance DOIT correspondre Ă  l’expression rĂ©guliĂšre ^([0]|([1-9][0-9]{0,17}))([.][0-9]{0,3}[1-9])?$

  • La longueur de cette instance est limitĂ©e comme ci-dessus Ă  23, avec 18 chiffres pour l’unitĂ© majeure et 4 pour l’unitĂ© mineure. Exemples valides : 124.45, 5, 5.5, 4.4444, 0.5, 0, 181818181818181818