# 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
trueoufalsede 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
AmountDOIT ĂȘ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
