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.

Obtenir l’offre d’une ligne

Méthode http : GET

URL de la requête :  URL BO Information Voyageur /api/v1/datas/idfm/lines/{code ligne}-netex.zip

  • code ligne : identifiant ilico de la ligne

Réponse

    HTTP 200 (OK) : la demande est acceptée et retourne l’offre au format Netex et 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