Lire en anglais

Partager via

Mise à jour vers la dernière version d’API Databricks SQL

  • Article

Cet article décrit les modifications apportées aux API Requêtes, Alertes, Autorisations et Sources de données incluses dans la dernière version de l’API Databricks SQL. Utilisez cet article pour vous aider à migrer vos applications et intégrations vers la nouvelle version d’API.

L’API héritée va continuer à être prise en charge pendant six mois. Cette période de transition vous donne le temps de migrer avant l’abandon de l’ancienne version.

Modifications apportées à l’API Requêtes

La nouvelle API Requêtes inclut une expérience utilisateur plus conviviale avec d’autres noms descriptifs, des réponses paginées et répertorient automatiquement les réponses triées par heure de création. La liste suivante décrit les modifications apportées à l’API Requêtes :

  • Le chemin d’accès de l’API est désormais api/2.0/sql/queries et remplace le chemin d’accès hérité de /api/2.0/preview/sql/queries.
  • Inclut une nouvelle définition de requête avec des types et des noms de champs plus descriptifs.
  • Le point de terminaison de mise à jour prend désormais en charge les mises à jour partielles en utilisant PATCH au lieu de POST.
  • Le point de terminaison de mise à jour prend désormais en charge le transfert de propriété de requêtes. Auparavant, cela n’était autorisé qu’à l’aide de l’API Transfert de propriété des objets.
  • Les réponses du point de terminaison de liste sont désormais paginées en utilisant la pagination basée sur un jeton.
  • Le point de terminaison de liste ne prend plus en charge le filtrage par nom ou par ordre personnalisé. Au lieu de cela, toutes les requêtes accessibles sont retournées et triées dans l’ordre croissant par leur heure de création.
  • Le point de terminaison de restauration n’est plus pris en charge. Les requêtes déplacées vers la corbeille peuvent continuer à être restaurées via l’interface utilisateur Azure Databricks.

Pour obtenir la documentation complète sur l’API Requêtes mise à jour, consultez Requêtes.

Modifications apportées à l’API Alertes

La nouvelle API Alertes inclut une expérience utilisateur plus conviviale avec des types et noms de champs plus descriptifs, des réponses paginées pour répertorier des points de terminaison et un support pour les mises à jour partielles. La liste suivante décrit les modifications apportées à l’API Alertes :

  • Le chemin d’accès de l’API est désormais api/2.0/sql/alerts et remplace le chemin d’accès hérité de /api/2.0/preview/sql/alerts.
  • Inclut une nouvelle définition d’alerte utilisée avec des types et des noms de champs plus descriptifs.
  • Le point de terminaison de mise à jour prend désormais en charge les mises à jour partielles en utilisant PATCH au lieu de POST.
  • Le point de terminaison de mise à jour prend désormais en charge le transfert de propriété de requêtes. Auparavant, cela n’était autorisé qu’à l’aide de l’API Transfert de propriété des objets.
  • Les réponses du point de terminaison de liste sont désormais paginées en utilisant la pagination basée sur un jeton.
  • Le point de terminaison de suppression déplace désormais l’alerte vers la corbeille au lieu de supprimer définitivement l’alerte. Les alertes déplacées vers la corbeille seront automatiquement supprimées après 30 jours. Les alertes mises à la corbeille peuvent être restaurées dans les 30 jours de la suppression via l’interface utilisateur Azure Databricks.

Pour obtenir la documentation complète sur l’API Alertes mise à jour, consultez Alertes.

Modifications apportées à l’API Autorisations

L’API Autorisations ne prend plus en charge Get object ACL et Set object ACL. Utilisez l’API Espace de travail pour gérer les autorisations pour ces actions.

API Sources de données marquée comme héritée

L’API Sources de données est désormais marquée comme héritée. Actuellement, ses fonctionnalités sont limitées à l’obtention d’une liste d’entrepôts SQL. Du fait que la nouvelle API Requêtes prend en charge la transmission et le retour des ID d’entrepôt SQL au lieu des ID de source de données, un appel d’API distinct pour la conversion entre les sources de données et les entrepôts SQL n’est plus requis.