2.0 (Octobre 2019)

La version 2.0 apporte un certain nombre de changements aux API, qui sont décrits ci-dessous. Plusieurs endpoints sont également réputés dépréciés et doivent être rapidement remplacés par leurs nouvelles versions, décrites dans la documentation.

Les utilisateurs de l'API sont invités à rendre leurs systèmes compatibles avec la nouvelle API au plus tôt.

2.0.1 (Novembre 2019)

  • Nombreuses corrections,

  • Mise à jour de la documentation Events pour refléter le nom des événements tels que véritablement envoyés par la plateforme (on-site-intervention-succeeded -> order-on-site-intervention-succeeded, on-site-intervention-failed -> order-on-site-intervention-failed), suppression de l'événement non implémenté pour le moment on-site-intervention-missed

  • Ajout des champs starter et pair dans l'événement order-completed (cuivre)

  • Ajout des champs start_date et end_date à l'événement cuivre appointment-agreed pour rapprochement avec l'API fibre

  • Changement du payload de résultat des diagnostics par souci d'uniformisation. Les résultats sont composés d'une première liste correspondant à chaque endpoint (un seul dans le cas de la fibre), puis d'une deuxième liste comprenant un ou plusieurs objets avec les résultats du diagnostic, selon les cas. Le nombre d'éléments peut varier en fonction du diagnostic et du succès ou non de la commande, il est donc important de mettre peu de contraintes sur le format des résultats.

Changements

  • De nombreux messages d'erreur ont été corrigés.

UUID et Operator Order Ref

  • Les UUIDs des objets Service et Order sont désormais de véritables UUIDs, représentés par leur forme canonique sur 32 caractères hexadécimaux. Les anciens UUIDs continuent à être utilisables pour accéder aux objets existants mais ils seront dépréciés prochainement. Les objets existants peuvent être récupérés et modifiés avec l'ancien et le nouvel UUID. Cependant, la valeur récupérée en réponse correspond au nouvel UUID sur 32 caractères,

  • La référence de commande opérateur (Operator Order Ref) doit maintenant être unique à travers toutes les technologies (cuivre et fibre).

API Cuivre

  • Pour s'aligner avec l'API fibre, le champ rivoli_code est remplacé par kosc_street_code et le champ insee_code est remplacé par kosc_insee_code dans les retours des API orders et services. Les API d'éligibilité et de rendez-vous sont inchangées (l'API de rendez-vous sera prochainement mise à jour pour fonctionner avec les codes Kosc),

  • Le champ origin est maintenant forcé à standard. Son utilisation est dépréciée,

  • Le champ batch_alias disparait,

  • Le champ profile_uuid est supprimé et remplacé par profile_name. Les UUIDs de profil sont dépréciés et les actions doivent désormais utiliser les noms de profils (voir Actions),

  • Suppression de champs spécifiques à Kosc (non documentés) dans l'objet endpoints[n].characteristics,

  • Suppression des champs nra et status dans endpoints[n] (redondants avec endpoints[n].characteristics.nra et endpoints[n].info.inactive),

  • Suppression du champ characteristics dans endpoints[n].info (non documenté et redondant avec endpoints[n].characteristics),

  • Le POST sur /orders/ retourne un code 201 en cas de succès et non plus 200,

  • Dans les cas create_nearby et create_neighbour, le champ endpoints de l'API order retourne maintenant la référence de l'endpoint livré par l'opérateur de boucle locale (et plus l'endpoint voisin utilisé pendant la commande).

  • Le champ type sur l'API Services disparait (anciennement collect ou enni).

  • Pour garantir le bon fonctionnement des commandes, les champs end_customer et bounds.address (ainsi que leurs sous champs) doivent respecter la règle suivante: tous les caractères utilisés pour ces champs doivent faire partie de cette liste (espace et espace insécable acceptés): ()+,-.0123456789:BCDEFGHIJKLMNO@APQRSTUVWXYZ[]_abcdefghijklmnopqrstuvwxyz{}~àâäçèéêëîïôöùûü

API Fibre

  • Les champs current_order_type et current_order_uuid ont été ajoutés dans l'API services,

  • Le champ locked a été ajouté dans l'API orders-endpoint. Il permet de savoir si la référence de l'endpoint est modifiable, en fonction du type de commande (activate ou create),

  • Le champ ticket_uuid est désormais un véritable UUID sur 32 caractères.

  • Pour garantir le bon fonctionnement des commandes, les champs end_customer et bounds.address (ainsi que leurs sous champs) doivent respecter la règle suivante: tous les caractères utilisés pour ces champs doivent faire partie de cette liste (espace et espace insécable acceptés): ()+,-.0123456789:BCDEFGHIJKLMNO@APQRSTUVWXYZ[]_abcdefghijklmnopqrstuvwxyz{}~àâäçèéêëîïôöùûü

Options des produits

  • Lorsqu'une option est désactivée, il n'est plus possible d'envoyer une valeur autre que null.

API Rendez-vous

  • Des messages d'erreur ont été corrigés ou précisés,

  • Les intervalles de dates acceptées étaient erronés dans la documentation. Si le niveau de service est standard, il est possible de prendre un rendez-vous dans 8 jours minimum (contre 6 précédemment). S'il s'agit d'un niveau de service Premium, le rendez-vous peut être pris dans 6 jours minimum (contre 8 précédemment).

API Événements

API Ticketing

  • Le paramètre uuid fait son apparition pour identifier uniquement un ticket et remplacera à terme le champ id.

Mise à jour de la documentation

  • Suppression de la rubrique API v2, qui est fusionnée avec la rubrique API. Toutes les APIs v1 qui avaient un équivalent v2 sont réputées dépréciées, en particulier :

    • L'API d'éligibilité dite "v2" est déplacée à la racine de la documentation API. L'API v1 est réputée dépréciée,

    • La page "comment commander une ligne" dite "v2" est déplacée à la racine de la documentation API. L'API précédente est réputée dépréciée,

  • La page "Endpoint" a été déplacée de "Champs communs" vers Commandes/Cuivre car leur structure n'est plus partagée avec l'API d'éligibilité (seulement avec l'API d'éligibilité v1, dépréciée),

  • L'authentification par token JWT dans l'URL est réputée dépréciée.

  • La page ticketing mentionnait à tort un paramètre size pour limiter le nombre de résultats. Le paramètre est en fait limit,

  • Ajout d'un avertissement sur la page Sandbox pour préciser qu'elle ne reflète pas les changements annoncés sur cette page.