FR_GU_API_Tempo_Like_Supply_Contract_v01.02

Guide d’Utilisation API Tempo Like Supply Contract Version 1.
GUIDE D’UTILISATION
API TEMPO LIKE SUPPLY CONTRACT
Version 1.2
Date d’entrée en vigueur : 24 Octobre 2019
1
Guide d’Utilisation API Tempo Like Supply Contract Version 1.2
SOMMAIRE
1 HISTORIQUE DU DOCUMENT ________________________________ 3
2 INTRODUCTION ________________________________________ 4
2.1 Définitions ........................................................................................... 4
2.2 Assistance technique ............................................................................ 5
3 DESCRIPTION FONCTIONNELLE DE L’API TEMPO LIKE SUPPLY CONTRACT __ 6

3.1 Description générale ............................................................................. 6
3.2 Pré-requis à l’utilisation des API ............................................................. 6
3.2.1 Confidentialité des données ...................................................................... 6
3.2.2 Résiliation ................................................................................................ 6
3.3 Ressource « tempo_like_calendars » ...................................................... 6
4 ACCES A L’API ________________________________________ 7

5 RESSOURCES EXPOSEES PAR L’API « TEMPO LIKE SUPPLY CONTRACT » ___ 8
5.1 Ressource /tempo_like_calendars .......................................................... 8
5.1.1 GET /tempo_like_calendars ...................................................................... 8
5.1.1.1 Modalités d’appel ............................................................................ 8
5.1.1.2 Entrées .......................................................................................... 8
5.1.1.3 Sorties ........................................................................................... 9
5.1.1.4 Règles de gestion ......................................................................... 13
5.1.1.5 Codes erreurs ............................................................................... 13
6 DETAILS DES ERREURS __________________________________ 15

6.1 Structure JSON : .................................................................................16
6.2 Structure XML : ...................................................................................16
6.3 Erreurs fonctionnelles ..........................................................................17
6.3.1 tempo_like_calendars ............................................................................. 17
6.4 Erreurs techniques...............................................................................18
7 ANNEXES ___________________________________________ 20
7.1 Fichiers Exemples ................................................................................20
FIN DU DOCUMENT _____________________________________ 20
2
1 Historique du document
Version Date Notes

1.1 22/02/2018 Création de l’API "Tempo Like Supply Contract"
1.2 21/10/2019 Ajout du paramètre en entrée "fallback_status" et du paramètre en sortie
"fallback"
3
2 Introduction
Ce document décrit l’API Tempo Like Supply Contract en version 1 mise à disposition par RTE à ses
Clients dans le but d’exposer la couleur des jours pour l’offre de type tempo.
Documents de référence
Référence Titre du document Référence complète

courte
[R1] CGU des API RTE Lien accès
2.1 Définitions
Les termes utilisés dans le Guide d’Utilisation et dont la première lettre est une majuscule sont définis
ci-dessous ou, à défaut, dans les Conditions Générales d’Utilisation [R1] :
API Application Programming Interface (Interface de programmation

applicative)
Authentification Mode de Protection permettant de s’assurer que l’identité de l’Émetteur ou
du Récepteur a été vérifiée par RTE et qu’il est donc autorisé à accéder au
SI et à utiliser les Applications.
Émetteur Partie qui émet un Message.
Message Ensemble de données informatiques destiné à véhiculer des informations et
structuré selon un ordre spécifié dans le Guide d’Utilisation. Un Message
peut être émis par l’Utilisateur ou RTE.
Opération Une opération est la manière dont le client interagit avec la ressource de
l’API. Il s’agit d’un verbe http (par exemple : GET pour lecture)
Partie ou Parties Dans le cadre du Guide d’Utilisation, il s’agit, individuellement, soit de RTE
soit de l’Utilisateur et, conjointement, de RTE et de l’Utilisateur.
Récepteur Partie qui reçoit le Message de l’Émetteur.
Ressource Une ressource représente la donnée sur laquelle l’application cliente
interagit.
URL Uniform Resource Locator : chaîne de caractères suivant un format
spécifique permettant de localiser une ressource sur un réseau et d’identifier
un moyen d’agir (protocole) sur cette ressource.
Utilisateur(s) Personne morale ayant validé les Conditions Générales d’Utilisation des API
de RTE et accédant au SI de RTE afin d’utiliser les API mises à dispositions
par RTE.
Traduction des valeurs anglaises retournées par l’API :
Valeur en Anglais en sortie de l’API Traduction en Français

BLUE Bleu
WHITE Blanc
RED Rouge
4
2.2 Assistance technique

En cas de difficulté pour l’accès ou l’utilisation d’une API, l’Utilisateur peut faire appel aux services
d’assistance téléphonique mis en place par RTE dans les conditions techniques prévues dans les
Conditions Générales d’Utilisation.
5
3 Description fonctionnelle de l’API Tempo Like Supply

Contract
3.1 Description générale

L’API permet d’accéder à la ressource permettant d’obtenir les données relatives à la fourniture
d’électricité de type Tempo. Cette ressource est uniquement accessible en lecture, via une opération de
type GET.
3.2 Pré-requis à l’utilisation des API

L’API Tempo Like Supply Contract est destinée aux acteurs du marché de l’électricité et au grand
public. Néanmoins les utilisateurs de l’API doivent créer un compte sur le portail digital de Rte. La
création de ce compte permet d’obtenir des identifiants Oauth 2.0. Ces identifiants sont ensuite requis
lors des appels aux API.
3.2.1 Confidentialité des données

Les informations contenues dans les Messages ne pourront être utilisées à d’autres fins que celles
prévues dans les Conditions Générales d’Utilisation [R1].
3.2.2 Résiliation
L’abonnement à une API est automatiquement résilié lorsque l’utilisateur supprime son compte sur le
portail Digital RTE.
Si l’Utilisateur souhaite ne plus utiliser une API sans résilier l’abonnement, il suffit de cesser l’émission
des appels à l’API.
3.3 Ressource « tempo_like_calendars »

Cette ressource permet de récupérer la couleur par jour des offres de fourniture de types Tempo. Les
offres de fourniture d’électricité de type Tempo comportent différents niveaux de prix, variables en
fonction de l’heure et des jours de l’année. Les jours rouges correspondent aux périodes de l’année où
la consommation est forte, les jours blancs à un niveau intermédiaire, et les jours bleus sont ceux de
plus faible consommation. Le prix correspondant à chaque type de jour est propre à chacun des
fournisseurs qui proposent ce type d’offres. RTE publie chaque jour la couleur du lendemain, qui
s’applique à tous les consommateurs ayant choisi une offre de fourniture de type Tempo, quel que soit
leur fournisseur.
6
4 Accès à l’API
L’accès à l’API décrite dans ce document se fait via le protocole REST.

Comme pour toutes les API mises à disposition par RTE, l’accès et l’utilisation de ces API sont soumis
aux termes des Conditions Générales d’Utilisation [R1].
La méthode d’autorisation d’accès aux API est OAuth, dont les usages sont décrits dans la FAQ.
7
5 Ressources exposées par l’API « Tempo Like Supply Contract

»
5.1 Ressource /tempo_like_calendars
5.1.1 GET /tempo_like_calendars
5.1.1.1 Modalités d’appel

La ressource est exposée de la manière suivante :
Exposition REST / JSON

Méthode GET
https://digital.iservices.rte-
URL ressource france.com/open_api/tempo_like_supply_contract/v1/tempo_like_calendars?start_
date=<valeur>&end_date=<valeur>&fallback_status=<valeur>
https://digital.iservices.rte-
URL sandbox (1)
france.com/open_api/tempo_like_supply_contract/v1/sandbox/tempo_like_calend
ars
(1)
La sandbox ne prend pas en compte les paramètres d’entrées, excepté le header Accept
Préconisations d’appels
Cette opération a pour objectif de permettre de récupérer la couleur du jour pour l’offre de type tempo.
Dans le cas d’utilisation nominal, il n’est pas nécessaire de renseigner les champs de la période. Le
service retourne automatiquement les données reçues pour le lendemain Cf. EC14-RG01.
Ce Service met à disposition des données à partir du 01/09/2014. Les données antérieures à cette
date ne sont pas disponibles.
Il est conseillé de faire un appel par jour à ce service vers 10h40 et de ne pas dépasser une période de
366 jours par appel.
5.1.1.2 Entrées
VALEURS /
NOM CARD. DESCRIPTION TYPE REGLES
FORMAT
Date de début des données YYYY-MM- TLC-RG01
start_date 0..1 date
demandées DDThh:mm:sszzzzzz1 TLC-RG02
Date de fin des données YYYY-MM- TLC-RG01
end_date 0..1 date
demandées DDThh:mm:sszzzzzz1 TLC-RG02
Indique si l’information sur le
TLCRG06
fallback_status 0..1 mode dégradé doit être boolean true ou false
TLCRG07
retournée en sortie du Service
1
Les dates en paramètre peuvent être exprimées sur n’importe quel fuseau horaire
Exemples d’appel :
Sans paramètre
8
URL:
GET /open_api/tempo_like_supply_contract/v1/tempo_like_calendars
HTTP/1.1
Headers:
Host: digital.iservices.rte-france.com
Authorization: Bearer CNAPbfmg7GjvtqTTlKqPm8ykP6R8YJFfJPnyjqW8p1v2PW2UX6bF8z
Body:
Avec tous les paramètres
URL:
GET /open_api/tempo_like_supply_contract/v1/tempo_like_calendars?start_date=2015-06-
08T00:00:00%2B02:00&end_date=2015-06-11T00:00:00%2B02:00&fallback_status=true
HTTP/1.1
Headers:
Host: digital.iservices.rte-france.com
Authorization: Bearer CNAPbfmg7GjvtqTTlKqPm8ykP6R8YJFfJPnyjqW8p1v2PW2UX6bF8z
Body:
5.1.1.3 Sorties
5.1.1.3.1. Format Json
tempo_like_calendars Tableau de valeurs {JSON} structuré comme suit :

Champ Card. Type Description Valeurs / Format Règles
TLC-RG03
Date de début des YYYY-MM-
start_date 1..1 date
données demandées DDThh:mm:sszzzzzz1 TLC-RG04
Date de fin des YYYY-MM-
end_date 1..1 date TLC-RG04
données demandées DDThh:mm:sszzzzzz1
values Une valeur par jour. Tableau de valeurs {JSON} structuré comme suit :
Intervalle de temps
start_date 1..1 date YYYY-MM-DDThh:mm:sszzzzzz1
début
0..n
end_date 1..1 date Intervalle de temps fin YYYY-MM-DDThh:mm:sszzzzzz1

Une des valeurs suivantes :
0..n
Couleur de l’offre de BLUE

value 1..1 enum
type tempo WHITE
RED
fallback 0..1 texte Mode dégradé true ou false
updated_date 1..1 date Date de mise à jour YYYY-MM-DDThh:mm:sszzzzzz1
1
Les dates en retour sont exprimées en heure française (UTC + 2 heures en été, UTC 1 heure en hiver)
Exemple de JSON retourné :
9
HTTP/1.1 200 OK
{"tempo_like_calendars":[
{
"start_date":"2015-06-02T00:00:00+02:00",
"end_date":"2015-06-03T00:00:00+02:00",
"values":[
{
"start_date":"2015-06-02T00:00:00+02:00",
"end_date":"2015-06-03T00:00:00+02:00",
"value":"WHITE",
"fallback":"true",
"updated_date":"2015-07-05T00:30:00+02:00"
}
]
}
]}
5.1.1.3.2. Format XML cas nominal
XSD de description du format de sortie :
STRUCTURE XML EN MODE NOMINAL

xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Tempo">
<xs:complexType>
<xs:sequence>
<xs:element type="xs:date" name="DateHeureCreation"/>
<xs:element type="xs:date" name="DateApplication"/>
<xs:element type="xs:string" name="Couleur"/>
<xs:element type="xs:string" name="Fallback"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Ce format est légèrement différent du format XML avec filtre pour des contraintes contractuelles avec
ses partenaires.
Exemple de XML retourné :
HTTP/1.1 200 OK
<Tempo>
<DateHeureCreation>2016-03-11</DateHeureCreation>
<DateApplication>2016-03-12</DateApplication>
10
<Couleur>BLEU</Couleur>
<Fallback>true</Fallback>
</Tempo>
5.1.1.3.3. Format XML avec filtre
XSD de description du format de sortie :
STRUCTURE XML SUR UNE PÉRIODE

GET /open_api/tempo_like_supply_contract/v1/tempo_like_calendars?start_date=2016-03-
01T00:00:00%2B01:00&end_date=2016-03-11T00:00:00%2B01:00
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"
<xs:element name="Tempos">
<xs:complexType>
<xs:sequence>
<xs:element name="Tempo" maxOccurs="unbounded" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element type="xs:date" name="DateHeureCreation"/>
<xs:element type="xs:date" name="DateApplication"/>
<xs:element type="xs:string" name="Couleur"/>
<xs:element type="xs:string" name="Fallback"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Ce format est aussi utilisé lors de la récupération d’une unique journée en renseignant les dates de
début (start_date) et les dates de fin (end_date).
Exemple de XML retourné :
GET /tempo_like_supply_contract/tempo_like_calendars/v1?start_date=2016-03-
01T00:00:00%2B01:00&end_date=2016-03-11T00:00:00%2B01:00
HTTP/1.1 200 OK
<Tempos>
<Tempo>
</Tempo>
<Tempo>
11
</Tempo>
<Tempo>
</Tempo>
<Tempo>
</Tempo>
<Tempo>
</Tempo>
<Tempo>
<Couleur>BLANC</Couleur>
</Tempo>
<Tempo>
<Couleur>BLANC</Couleur>
</Tempo>
<Tempo>
</Tempo>
<Tempo>
</Tempo>
<Tempo>
12
</Tempo>
</Tempos>
5.1.1.4 Règles de gestion

Règle de gestion en fonction des paramètres d’entrée :
Paramètres en entrées Description Numéro

fallback_
start_date end_date
status
Si aucun paramètre d’entrée n’est renseigné, la
vide vide ressource retourne la couleur du jour la plus TLC-RG01
récente.
Si les champs start_date et end_date sont
renseigné renseigné renseignés, la ressource retourne toutes les TLC-RG02
couleurs des jours de cette période.
Si non renseigné ou si renseigné à false, alors le
vide champ fallback ne sera pas fourni en sortie du TLC-RG06
Service.
Si renseigné à true alors, en sortie du Service, le
renseigné champ fallback sera donné uniquement pour les TLC-RG07
données du jour et du lendemain.
Règles de gestion appliquées en sortie :
Numéro Description
Les données de sortie sont triées par date de début (start_date) de la plus récente à la
TLC-RG03
plus ancienne.
TLC-RG04 En sortie de la ressource la couleur est retournée à la maille jour calendaire.
Cette ressource permet à l’application appelante de choisir le format de restitution des

données. Les formats disponibles sont soit en XML, soit en JSON. Si rien n’est précisé par
l’application appelante, la ressource retourne les données au format JSON.
TLC-RG05
Pour obtenir les données au format XML, l’application appelante doit spécifier dans l’entête
de la requête :
 Accept : application/xml
5.1.1.5 Codes erreurs
Le tableau suivant liste les codes erreurs pouvant être retournés lors de l'appel à la ressource.
Le détail de ces erreurs est décrit au chapitre
13
Détails des erreurs.
Type d’erreur Code erreur Détails

Fonctionnelle TMPLIKSUPCON_TMPLIKCAL_F01 §6.3.1
Technique 401 §0
Technique 403 §0
Technique 404 §0
Technique 408 §0
Technique 413 §0
Technique 414 §0
Technique 429 §0
Technique 500 §0
Technique 503 §0
Technique 509 §0
14
6 Détails des erreurs

Le schéma ci-dessous présente les codes retournés à l’Utilisateur de l’API en fonction du séquencement
des appels.
Ce paragraphe concerne les erreurs communes à toutes les ressources de l’API et à ce titre il ne décrit
pas les erreurs de requêtes (code http 400). Ces erreurs sont décrites ressource par ressource dans le
paragraphe correspondant.
En cas d’erreur lors de la phase d’authentification (validation du login et du mot de passe) un code
HTTP 401 « unauthorized » est retourné à l’appelant.
La seconde étape est de vérifier que l’Utilisateur ne dépasse pas le nombre maximal d’appels autorisés
pour l’opération. En cas de dépassement, l’appelant en est informé par un code HTTP 429. La réponse
du serveur contient dans ce cas un entête "Retry-After:" indiquant le temps d'attente (en secondes)
que le client doit attendre avant de renvoyer sa demande.
La troisième étape est de vérifier si l’appelant (identifié par le jeton OAuth2 ou le certificat PKI) a bien
créé une application sur le Portail Data. Si ce n’est pas le cas l’appelant en est informé par un code
HTTP 403 « forbidden ».
La quatrième étape consiste à vérifier si l'API est bien associée à l’application (notion d'abonnement).
Si ce n’est pas le cas, l’appelant en est informé par un code HTTP 403 « forbidden ».
La cinquième étape consiste à accéder aux ressources de RTE. Diverses erreurs fonctionnelles peuvent
se produire. Celles-ci sont communiquées à l’Utilisateur en tant qu’erreur JSON avec un code http 400.
En cas d’incident technique lors du traitement de la requête quelle que soit l’étape, l’appelant en sera
informé par un code HTTP 500.
15
6.1 Structure JSON :
{
"error": "libelle_court, codification explicite de l’erreur",
"error_description": "libellé long, lisible par un utilisateur",
"error_uri": "URI vers le guide d’utilisation de l'API ou la FAQ/documentation sur le Portail
Data "
"error_details" : {
"transaction_id" : "identifiant unique d’appel, utile en cas d’incident"
}
}
 Le libellé court (« error ») est un code permettant à l’application appelante de traiter

automatiquement les messages des erreurs. Il est représenté par une suite de mots séparés
par des « _ ».
 Le libellé long (« error_description ») est une description permettant aux utilisateurs de
comprendre de façon plus précise l’origine de l’erreur. Ce libellé doit être validé par le métier
afin de s’assurer qu’il est suffisamment explicite.
 L’URI vers le guide d’utilisation est présent pour donner plus d’explications en fonction de l’Api
appelée.
 Le champ transaction_id : fournit un identifiant unique d’appel. Cet identifiant peut être
communiqué aux services d’assistance RTE en cas d’incident.
6.2 Structure XML :
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"

<xs:element name="error">
<xs:complexType>
<xs:sequence>
<xs:element type="xs:string" name="error"/>
<xs:element type="xs:string" name="error_description"/>
<xs:element name="error_details">
<xs:complexType>
<xs:sequence>
<xs:element type="xs:string" name=" transaction-id"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
16
 Le libellé court <error/> est un code permettant à l’application appelante de traiter

automatiquement les messages des erreurs. Il est représenté par une suite de mots séparés
par des « _ ».
 Le libellé long <error_description/> est une description permettant aux utilisateurs de
comprendre de façon plus précise l’origine de l’erreur. Ce libellé doit être validé par le métier
afin de s’assurer qu’il est suffisamment explicite.
 L’URI vers le guide d’utilisation est présent pour donner plus d’explications en fonction de l’Api
appelée.
 La balise <transaction_id/> fournit un identifiant unique d’appel. Cet identifiant peut être
utilisé pour communiquer avec RTE en cas d’incident.
6.3 Erreurs fonctionnelles
6.3.1 tempo_like_calendars
Ce tableau récapitule les erreurs fonctionnelles retournées par la ressource correspondant à une erreur
dans la requête (code http 400) :
TMPLIKSUPCON_TMPLIKCAL_F01
Cette erreur est générée si les paramètres start_date et end_date sont passés l’un
RG
sans l’autre.
If one of the fields "start_date" or "end_date" is used, the two fields are mandatory.
Message
Please used either fields or neither.
Exemple GET open_api/tempo_like_supply_contract/v1/tempo_like_calendars?start_date=2015-
d'appel 06-01T00:00:00%2B02:00
Cette erreur est générée si le paramètre start_date est plus récent que le paramètre
RG
end_date.
The field "start_date" in the API input is more recently than the field "end_date". Please
Message
correct the values of these fields
d'appel 06-02T00:00:00%2B02:00&end_date=2015-06-01T00:00:00%2B02:00
RG Cette erreur est générée si la période demandée est supérieure à 366 jours.
The API does not provide feedback on such a long period in one call. To retrieve all the
Message
data please make it with severals calls to the API.
RG Cette erreur est générée si end_date est supérieur à J+2 par rapport à la date système.
Message The value of "end_date" field is incorrect. It is not possible to recover data to this term.
Cette erreur est générée si l’intervalle de temps entre start_date et end_date est
RG
inférieur 1 jour calendaire.
The period filled by fields "start_date" and "end_date" is too short to return values. Please
Message
check the user guide to verify the minimum period for this API.
17
Cette erreur est générée si au moins un des paramètres start_date ou end_date n’a
RG
pas le format attendu
One of the dates in the API input does not follow the format described in the user guide.
Message
Please verify compliance with the format for each field.
d'appel 06-01&end_date=2015-06-01
RG Cette erreur est générée si le champ fallback_status n’a pas la valeur true ou false.
One of the enumerated field does not match with the list of expected values. Please verify
Message
compliance with the format for each field.
d'appel 06-01&end_date=2015-06-01&fallback_status=status
6.4 Erreurs techniques
401
Code http 401
Message unauthorized
Description Erreur générée lorsque l’authentification a échouée
403
Code http 403
Message Forbidden
Description Erreur générée si l’appelant n’est pas habilité à appeler la ressource
404
Code http 404
Message Not Found
Description La ressource appelée n’existe pas ou aucune page n’a été trouvée
408
Code http 408
Message Request Time-out
Erreur générée sur non réponse du service appelé ou retour en timeout (http
Description
408) du service appelé.
413
Code http 413
Message Request Entity Too Large
Description La taille de la réponse de la requête dépasse 7Mo
414
Code http 414
Message Request-URI Too Long
Description L’URI transmise par l’appelant dépasse 2048 caractères.
18
429
Code http 429
Message Too Many Requests
Description Le nombre d’appel maximum dans un certain laps de temps est dépassé.
500
Code http 500
Message Internal Server Error
Toute autre erreur technique.
Description (Cette erreur est accompagnée d’un message JSON avec un champ error_code
et error_description)
503
Code http 503
Message Service Unavailable
Description Erreur générée sur maintenance (http 503).
509
Code http 509
Message Bandwidth Limit Exceeded.
Description L‘ensemble des requêtes des clients atteint la limite maximale.
19
7 Annexes
7.1 Fichiers Exemples

Une fois l’Utilisateur connecté sur le Portail Data, des exemples de fichiers (notamment les réponses de
l’API) sont disponibles en ligne avec le descriptif de l'API.
FIN DU DOCUMENT
20

FR_GU_API_Tempo_Like_Supply_Contract_v01.02

Transféré par

Droits d'auteur :

Formats disponibles

FR_GU_API_Tempo_Like_Supply_Contract_v01.02

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

FR_GU_API_Tempo_Like_Supply_Contract_v01.02

Transféré par

Droits d'auteur :

Formats disponibles

Guide d’Utilisation API Tempo Like Supply Contract Version 1.

Date d’entrée en vigueur : 24 Octobre 2019

3 DESCRIPTION FONCTIONNELLE DE L’API TEMPO LIKE SUPPLY CONTRACT __ 6

4 ACCES A L’API ________________________________________ 7

6 DETAILS DES ERREURS __________________________________ 15

FIN DU DOCUMENT _____________________________________ 20

Version Date Notes

Référence Titre du document Référence complète

API Application Programming Interface (Interface de programmation

Traduction des valeurs anglaises retournées par l’API :

Valeur en Anglais en sortie de l’API Traduction en Français

2.2 Assistance technique

3 Description fonctionnelle de l’API Tempo Like Supply

3.1 Description générale

3.2 Pré-requis à l’utilisation des API

3.2.1 Confidentialité des données

3.3 Ressource « tempo_like_calendars »

L’accès à l’API décrite dans ce document se fait via le protocole REST.

5 Ressources exposées par l’API « Tempo Like Supply Contract

5.1 Ressource /tempo_like_calendars

5.1.1 GET /tempo_like_calendars

5.1.1.1 Modalités d’appel

Exposition REST / JSON

Avec tous les paramètres

tempo_like_calendars Tableau de valeurs {JSON} structuré comme suit :

end_date 1..1 date Intervalle de temps fin YYYY-MM-DDThh:mm:sszzzzzz1

Couleur de l’offre de BLUE

Exemple de JSON retourné :

5.1.1.3.2. Format XML cas nominal

XSD de description du format de sortie :

STRUCTURE XML EN MODE NOMINAL

Exemple de XML retourné :

5.1.1.3.3. Format XML avec filtre

XSD de description du format de sortie :

STRUCTURE XML SUR UNE PÉRIODE

Exemple de XML retourné :

5.1.1.4 Règles de gestion

Paramètres en entrées Description Numéro

Règles de gestion appliquées en sortie :

TLC-RG04 En sortie de la ressource la couleur est retournée à la maille jour calendaire.

Cette ressource permet à l’application appelante de choisir le format de restitution des

5.1.1.5 Codes erreurs

Détails des erreurs.

Type d’erreur Code erreur Détails

Fonctionnelle TMPLIKSUPCON_TMPLIKCAL_F03 §6.3.1

Fonctionnelle TMPLIKSUPCON_TMPLIKCAL_F04 §6.3.1

Fonctionnelle TMPLIKSUPCON_TMPLIKCAL_F05 §6.3.1

Fonctionnelle TMPLIKSUPCON_TMPLIKCAL_F06 §6.3.1

Fonctionnelle TMPLIKSUPCON_TMPLIKCAL_F07 §6.3.1

6 Détails des erreurs

6.1 Structure JSON :

 Le libellé court (« error ») est un code permettant à l’application appelante de traiter

6.2 Structure XML :

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"

 Le libellé court <error/> est un code permettant à l’application appelante de traiter

6.3 Erreurs fonctionnelles

6.4 Erreurs techniques

7.1 Fichiers Exemples

Vous aimerez peut-être aussi