CHANGELOG

---

Terminologie utilisée dans le changelog :

• applicatif chauffeur: application utilisée par le chauffeur du taxi pour envoyer sa géolocalisation en temps réel à l'API le.taxi et répondre aux demandes de courses.
• applicatif client: application utilisée par un client souhaitant commander un taxi.
• ZUPC: Zone Unique de Prise en Charge, c'est à dire la zone sur laquelle un taxi est autorisé à prendre un client sur la voie publique sans justifier d'une réservation préalable.

---

8/2/2023

• Ajout d'un champ "pmr" pour les véhicules homologués. Le champ "special_need_vehicule" n'a jamais été clair dans son usage, et il est maintenant obsolète (toujours utilisable mais masqué).

7/11/2022

• Montée de version des images de dev et prod à Ubuntu 22.04 (sans impact sur l'API).

5/10/2022

• Mise en place de statistiques d'activité (sans impact sur l'API).

13/09/2022

• Affichage des taxis sous un nom d'opérateur neutre (non encore activé en prod).

25/08/2022

• Les courses ne sont plus visibles après deux mois.

05/07/2022

• Les numéros de téléphone sont cachés tant que les deux parties n'ont pas confirmé leur accord. L'objet Hail affiche les vrais numéros de téléphone ensuite.

07/04/2022

• Documentation sur le déroulé d'une course et diagnostic d'un taxi manquant.
• La doc legacy a été remplacée pour de bon.

24/03/2022

• Ajout d'un bouton pour positionner un taxi ou un client de test à une adresse donnée dans le simulateur.

15/03/2022

• Changement interne pour simplifier la documentation et l'usage de l'API sans casser la compatibilité chez les partenaires historiques.

14/03/2022

• Correction d'un bug sur la validation de l'en-tête HTTP dans la section "mon compte" quand on n'utilise pas cette fonctionnalité.

07/03/2022

• Documentation sur le comportement quand on POST une ressource existante.
• Refonte du Swagger : les champs obsolètes sont marqués comme tel, les champs ignorés à l'étape de la création ou de l'édition sont cachés dans la documentation correspondante, et indication de quel endpoint est pour quel acteur (opérateur ou client).

21/02/2022

• Restauration temporaire des champs à usage interne que des partenaires historiques ont utilisé, puisque Swagger les exposait sans distinction.

17/02/2022

• Renforcement des contrôles sur les requêtes de l'API : rejet de valeurs vides, de champs à usage interne, validation stricte des coordonnées WSG 84 et vérification de la conformité HTTP de l'en-tête déclarée dans "mon compte".

10/02/2022

• L'API fait maintenant un minimum de vérifications sur l'immatriculation et peut rejeter des valeurs de test trop fantaisistes.

07/02/2022

• Intégration : Créer un taxi de test dans une commune de son choix

26/01/2022

• Mise à jour de la liste des communes au 1er janvier 2022

06/01/2022

• API : ajout d'un endpoint /towns qui expose la liste des communes utilisées par l'API pour valider l'inscription des taxis.

05/01/2022

• Documentation : tutoriaux opérateur et application chauffeur (et leurs projets de démo).

16/11/2021

• API : il est maintenant possible de changer le rayon de visibilité d'un taxi.
• Console : la documentation continue de s'enrichir avec des guides thématiques.

02/08/2021

• Console : première mise à jour de la section documentation. Dans les semaines à venir, la documentation sera entièrement réorganisée en quatre sections : les tutoriels à suivre pour créer simplement une application, les guides thématiques qui fournissent des explications de base, la documentation de référence qui détaille de manière exhaustive les fonctionnalités de l'API et les guides pratiques qui donnent des exemples à appliquer pour répondre à des problèmes spécifiques.

06/07/2021

• API: les applicatifs clients peuvent désormais récupérer la localisation d'un taxi dès l'émission d'un hail via GET /hails/:id, et non plus uniquement à partir du moment de l'acceptation de la part du taxi. Cette demande a été effectuée par un des partenaires afin de rétablir un ancien comportement supprimé il y a plusieurs mois. Nous ne considérons pas qu'il est problématique de fournir la géolocalisation du taxi via cet endpoint même avant l'acceptation de la course par le chauffeur, car celle-ci est quoi qu'il en soit disponible via GET /taxis à tout moment.

05/07/2021

• API: l'endpoint POST /vehicles utilisé par les applicatifs chauffeurs accepte les paramètres engine, horodateur, taximetre et engine. Une erreur 500 était retournée suite à de récentes modifications lorsque ces champs étaient à null. L'erreur est corrigée, il est désormais possible de fournir le champ à null.

15/06/2021

• Mise à jour des schémas de la documentation, à nouveau en phase avec l'API.

02/06/2021

• Changement de quelques exemples de la documentation pour des valeurs plus réalistes.

31/05/2021

• Liens directs (ancres) sur les sous-sections de la documentation d'intégration.

04/05/2021

• Le dashboard "courses" de la console permet désormais d'accéder aux détails d'une course, et de lister les transitions d'état afin de faciliter le debug de vos applications.

03/05/2021

• L'endpoint GET /hails affiche désormais le customer_id, et accepte le filtre ?customer_id.

28/04/2021

• Ajout d'un endpoint /zupc/live qui liste les différentes ZUPC et le nombre de taxis connectés.

14/04/2021

• Console: les applicatifs clients ont désormais accès à un tableau de bord "courses par utilisateur", qui présentent les sessions utilisateurs.
• Console: les applicatifs chauffeurs peuvent désormais voir le nombre de leurs chauffeurs connectés dans une ZUPC dans le tableau de bord "taxis en ligne".

13/04/2021

• API: Correction d'un bug empêchant un opérateur de voir tous ses taxis dans le cercle affiché sur la carte.

12/04/2021

• Console: le tableau de bord "taxis en ligne" a un nouveau bouton "chercher une adresse" afin de localiser la carte simplement à une adresse donnée.

07/04/2021

• Console: ajout d'un lien vers le formulaire de demande d'accès sur la page de login.
• Console: nouveau tableau de bord pour afficher les taxis en ligne autour d'un point. L'interface est disponible sur https://console.api.taxi/dashboards/map et https://console.dev.api.taxi/dashboards/map. Les applicatifs client peuvent voir tous les taxis disponibles. Les applicatifs chauffeur peuvent voir uniquement les taxis qu'ils ont enregistrés.
• Console: la liste des taxis de l'opérateur affiche la ville de l'autorisation de stationnement au lieu du simple code INSEE.
• Console: documentation du nouveau point d'accès /geotaxi/ pour remonter la géolocalisation des taxis de l'opérateur.
• Console: (bugfix) le tableau de bord "taxis enregistrés" accessible pour les applicatifs chauffeur ne pouvait afficher que la première page du tableau.

29/03/2021

• Une nouvelle version console est disponible sur console.api.taxi et dev.api.taxi. Elle a été entièrement réécrite afin de faciliter des évolutions futures.

22/03/2021

• L'endpoint GET /users permet aux managers de flotte de lister les comptes en gestion.
• PUT /hails/:id et PUT /taxis/:id: une erreur était retournée lorsque les données envoyées étaient vides ({"data": []}). Le problème a été réglé.
• PUT /users/:id: possibilité de modifier son mot de passe.
• Pagination: les endpoints paginés exposent désormais le champ per_page, qui contient le nombre de résultats maximum pour chaque page.
• GET /hails: possibilité de filtrer partiellement par id, status, date, opérateur, applicatif client ou taxi.
• Ajout de GET /taxis/all pour lister tous les taxis d'un opérateur.
• Ajout du header X-Logas: un manager de flotte peut spécifier le header X-Logas afin de se connecter en tant que le compte en gestion.
• Suppression du champ inutilisé internal_id pour décrire un véhicule.
• Ajout d'un endpoint POST /geotaxi/ pour envoyer la position des taxis par lot (jusqu'à 50 par requête) en remplacement du serveur UDP, documentation disponible sur la nouvelle console.

12/01/2021

Authentification requise pour /zupc

L'endpoint /zupc?lon=xx&lat=yy retourne des informations sur la ZUPC, dont le nombre de taxis actuellement connectés. Cet endpoint requiert désormais de fournir un token d'API valide.

05/01/2021

Nettoyage de la base de données, correction des doublons

Les endpoints suivants sont exposés aux applicatifs chauffeur :

• POST /ads pour créer un ADS
• POST /driver pour créer un nouveau chauffeur
• POST /taxis pour créer un nouveau taxi

Chacun de ces endpoints retourne la resource si elle existe déjà.

• un ADS existe déjà si une ADS a déjà été enregistrée par l'opérateur avec les mêmes numero et insee
• un chauffeur existe déjà si un chauffeur a déjà été enregistrée par l'opérateur avec les mêmes departement et professional_licence
• un taxi existe déjà si un taxi a déjà été enregistré par l'opérateur avec les mêmes ads, vehicle et driver

Une ancienne version de l'API avait un bug. Sous certaines conditions, un nouvel objet était enregistré en base de données au lieu de retourner l'objet existant. Il était donc possible d'avoir deux ADS avec un identifiant différent, mais ayant le même numero et insee. La situation est similaire pour les chauffeurs et les taxis.

Nous avons effectué les changements suivants :

• Correction du bug : on retourne toujours l'ADS, le chauffeur ou le taxi existant si il existe déjà
• Suppression des données doublonnées : pour chaque ADS, chauffeur ou taxi, si il existe plusieurs entrées, on ne garde que celle créée en dernier, les doublons sont supprimés
• Correction des données ayant une référence : pour chaque donnée référençant une donnée supprimée, on met à jour la référence vers la seule qui est gardée.
• Suppression des données "orphelines" : nous avons supprimé tous les ADS, chauffeurs et véhicules ayant été enregistrés, mais n'étant pas référencés par un taxi.

Concrètement, les changements que vous pourriez remarquer :

• Je fais un POST /drivers, POST /ads ou POST /taxi : auparavant, pour les mêmes paramètres en entrée, j'avais possiblement un nouvel objet à chaque fois. Désormais, l'objet existant est retourné.
• En tant qu'applicatif client, je liste les courses avec GET /hails. Le taxi_id des courses a possiblement changé, si la course référençait un taxi qui a été supprimé, pour référencer le taxi avec l'identifiant créé le plus récemment.

16/12/2020

Création d'un type de compte "gestionnaire"

L'API dispose actuellement de deux types de comptes : "applicatif chauffeur" (ou "operateur") et "applicatif client" (ou "moteur"). Ces comptes peuvent être rattachés à un nouveau type de compte "gestionnaire" afin d'en déléguer l'administration.

Changement de statut dans la fonctionnalité "intégration"

Le menu "Intégration" de la console de développement vous permet de simplement simuler un applicatif chauffeur ou un applicatif client afin de faciliter la création de votre application.

Lorsque le statut de la course est received_by_taxi, l'API permet à l'applicatif client de changer le statut à declined_by_customer. La console web propose désormais cette action.

10/12/2020

Bugfix de la console de développement

Le menu Intégration de la console de développement effectue des requêtes sur l'API. Les éventuelles erreurs retournées par celle-ci sont désormais affichées correctement, et ne génèrent plus une page d'erreur sur la console.

08/12/2020

Changement de POST /vehicles

model et constructor peuvent désormais être null

L'endpoint POST /vehicles accepte les paramètres optionnels model et constructor. Une erreur 500 était retournée dans le cas où ces valeurs étaient définies à null. Le problème a été corrigé.

Possibilité de modifier un véhicule

L'API le.taxi créée il y a plusieurs années s'approche du standard REST mais ne le suit pas complètement. Pour des raisons de rétro-compatibilité, il n'est plus possible de suivre le standard.

L'endpoint POST /vehicles permet de créer un véhicule et retourne un code HTTP/201 pour un nouveau véhicule créé. Si le véhicule existe déjà, HTTP/200 est désormais retourné. Les paramètres spécifiés dans le body de la requête permettent désormais de modifier le véhicule : auparavant, ils étaient ignorés pour un véhicule existant.

07/12/2020

Suppression du changement automatique du statut d'un hail lors de la modification du statut d'un taxi

Comme l'explique notre documentation, un hail a le statut suivant (cette liste n'est pas exhaustive) :

• received lors de sa création
• received_by_operator puis received_by_taxi
• accepted_by_taxi si le taxi accepte la course
• accepted_by_customer si le client accepte la course
• customer_on_board lorsque le taxi déclare le client à bord
• finished lorsque la course s'est terminée

Le changement du statut du hail se fait par un PUT /hails/:id.

En effectuant un PUT /taxis/:id on peut changer le statut d'un taxi, qui a une des valeurs suivantes :

• free lorsque le taxi est en maraude et prêt à accepter des courses
• occupied lorsque le taxi est "rouge" et n'est pas disposé à accepter des courses
• off lorsque le taxi n'est pas en ligne

Avant la modification apportée en production :

• lorsqu'un taxi avait une course en cours avec le statut accepted_by_customer et qu'une requête à PUT /taxis/:id était effectuée pour changer le statut du taxi de free à occupied, le statut du hail était automatiquement mis à customer_on_board.
• lorsqu'un taxi avait une course en cours avec le statut customer_on_board et qu'une requête à PUT /taxis/:id était effectuée pour changer le statut du taxi de occupied à free ou off, le statut du hail était automatiquement changé à finished.

La modification automatique du statut du hail après un changement du statut du taxi n'est plus d'actualité. Pour déclarer le client à bord, il faut désormais obligatoirement effectuer un PUT /hails/:id avec le statut customer_on_board, et avec le statut finished pour terminer la course.

04/12/2020

Réduction du timeout de la double confirmation

L'applicatif client effectue une demande de course que le taxi accepte. Le statut de la course est accepted_by_taxi. Auparavant, l'applicatif client avait 60 secondes pour confirmer la demande du client. Suite aux demandes de plusieurs fournisseurs d'applicatif client, ce délai a été réduit à 20 secondes afin de ne pas faire patienter le taxi trop longtemps et d'augmenter la fiabilité de la prise en charge.

01/12/2020

Applicatif client: ajout du paramètre session_id lors de la création d'une course

Un utilisateur souhaitant commander un taxi effectue une demande sur son applicatif client. Cet applicatif peut effectuer plusieurs requêtes à l'API le.taxi afin de trouver un taxi qui puisse répondre à la demande de course. On parle de "session" pour désigner toutes les requêtes effectuées pour répondre à la demande de l'utilisateur.

L'endpoint d'API POST /hails permet d'effectuer une demande de course. Cet appel nécessite plusieurs paramètres, dont l'identifiant du client effectuant la course. La réponse retournée contient un session_id. Les futurs appels à POST /hails pour ce client peuvent fournir ce même session_id.

Si le session_id n'est pas fourni et qu'une demande de course a été effectuée par le client moins de cinq minutes auparavant, le session_id de la course précédente est retourné.

Cet identifiant de session nous permet de créer des tableaux de bord.

Applicatif chauffeur: bugfix sur mymap

mymap est l'outil de visualisation des taxis, disponible sur https://dev.api.taxi/mymap/ pour l'environnement de développement et https://api.taxi/mymap/ pour l'environnement de production.

Il arrivait que le nombre de taxis connectés dans la ZUPC soit faux. Le problème est désormais corrigé.