API Publication
Les offres agrégées et validées par le IBOO sont consultables par les API de publication.
Celles-ci sont de type RESTful.
IBOO met à disposition de ses utilisateurs la possibilité d’importer ses données par une API.
La description et l’utilisation de cette API (parmi d’autres) est disponible dans de nombreux langages via notre notre documentation Postman.
Postman permet l’utilisation de toutes les requêtes fournies si vous voulez créez votre propre espace (Voir le bouton “Run in Postman“ en haut à droite).
Protocole
Les requêtes utilisent la méthode http GET, pour les consultations (collection ou ressource).
Toutes les requêtes retournent :
un code HTTP 200 (OK) : en cas de succès
un code HTTP 400 (Bad Request) : lorsque l’action ou le type sont inconnus.
un code HTTP 406 (Not Acceptable) : lorsque les données fournies ne permettent de traiter la demande
un code HTTP 500 (Internal Server Error) : en cas d’erreur du IBOO
Les chapitres suivant ne détailleront que les requêtes avec un code de réponse HTTP 200 apportant une information supplémentaire.
Les URL des requêtes HTTP font apparaître différentes parties variables qui sont notées selon la règle ci-dessous :
Une partie obligatoire pouvant avoir différents contenus, ces contenus pouvant ou non appartenir à une liste de valeurs autorisées, est notée entre { }.
Par exemple : http://mon_domaine/{mes_ressources}, la partie {mes_ressources} nécessite de renseigner une chaine non vide.
Une partie optionnelle pouvant avoir différents contenus, ces contenus pouvant ou non appartenir à une liste de valeurs autorisées, est notée entre [ ].
Par exemple : http://mon_domaine/lines[/single], la partie [/single] est optionnelle.
Sécurité
L’authentification est réalisée en utilisant une authentification par token. L’appelant doit utiliser un token d’API fournie par IDFm.
Ce token est à placer dans le champs “Authorization” du header avec la valeur :
Token token=publication_api_key
Tous les accès à l’API se font en HTTPS.
NeTEx
Les appels par API NeTEx pour récupérer les fichiers publiés retournent dans les headers de la réponse :
ETag : un identifiant représentant la version d’un fichier accessible à une URL
Last-Modified : Date de dernière modification du fichier accessible à une URL
< ETag: W/"b0b39f188d276c096c657c172eec6284"
< Last-Modified: Thu, 06 Feb 2020 21:34:29 GMT
Ces appels peuvent donc prendre en requête les en-têtes :
HTTP_IF_NONE_MATCH : pour transmettre un identifiant de contenu (etag) unique
HTTP_IF_MODIFIED_SINCE : pour transmettre l'horodatage de la dernière modification du contenu.
Si le navigateur fait une demande avec l'identifiant de contenu (etag) ou la dernière modification depuis l'horodatage correspond à la version du serveur, alors le serveur renvoie une réponse vide avec un état non modifié avec un code HTTP 304.
Obtenir l'Offre IDF
Méthode http ; GET
URL de la requête : URL BO Information Voyageur /api/v1/datas/idfm/netex.zip
Réponse :
HTTP 200 (OK) : la demande est acceptée et retourne l’offre au format Netex d’une profondeur fixe (4 semaines par défaut) sous la forme d’une archive zip organisée comme décrit au § A.1 Types de publications.
Ce document est la propriété d'enRoute et ne peut être reproduit sans son accord écrit