Développer avec les API REST pour Reporting Services

  • Article

S'applique à : SQL Server Reporting Services (2017 et ultérieur) ❌ Power BI Report Server

Microsoft SQL Server 2017 Reporting Services prend en charge les API REST (Representational State Transfer). Les API REST sont des points de terminaison de service prenant en charge des opérations HTTP (méthodes) qui fournissent, créent, récupèrent, mettent à jour ou suppriment l'accès aux ressources d'un serveur de rapports.

L'API REST fournit un accès par programmation aux objets d'un catalogue de serveur de rapports SQL Server 2017 Reporting Services. Parmi ces objets figurent les dossiers, les rapports, les indicateurs de performance clés, les sources de données, les jeux de données, les plans d'actualisation et les abonnements. À l'aide de l'API REST, vous pouvez, par exemple, parcourir l'arborescence des dossiers, découvrir le contenu d'un dossier ou télécharger une définition de rapport. Vous pouvez également créer, mettre à jour et supprimer des objets. Parmi les exemples d'utilisation d'objets, citons le téléchargement d'un rapport, l'exécution d'un plan d'actualisation, la suppression d'un dossier, etc.

Remarque

Si vous voulez voir ou supprimer des données personnelles, consultez les conseils de Microsoft sur le site Demandes des personnes concernées pour Windows concernant le RGPD. Si vous recherchez des informations générales sur le RGPD, consultez la section RGPD du portail d'approbation de services.

Composants d'une demande/réponse d'API REST

Une paire demande/réponse d'API REST peut être divisée en cinq composants :

  • L'URI de demande, qui se compose de : {URI-scheme} :// {URI-host} / {resource-path} ? {query-string}. Bien que l'URI de demande soit inclus dans l'en-tête de message de la demande, nous l'appelons séparément ici, car la plupart des langages ou des frameworks vous obligent à le transmettre séparément du message de demande.

    • Schéma d'URI : indique le protocole utilisé pour transmettre la demande. Par exemple, http ou https.
    • Hôte de l'URI : spécifie le nom de domaine ou l'adresse IP du serveur où le point de terminaison de service REST est hébergé, tel que myserver.contoso.com.
    • Chemin de la ressource : spécifie la ressource ou la collection de ressources, qui pourraient inclure plusieurs segments utilisés par le service pour déterminer la sélection de ces ressources. Par exemple : CatalogItems(01234567-89ab-cdef-0123-456789abcdef)/Properties peut être utilisé pour obtenir les propriétés spécifiées pour le CatalogItem.
    • Chaîne de requête (facultative) : fournit plus de paramètres simples, tels que la version de l'API ou les critères de sélection des ressources.

  • Champs d'en-tête de message de requête HTTP :

    • Méthode HTTP requise (également appelée opération ou verbe), qui indique au service le type d'opération que vous demandez. Les API REST Reporting Services prennent en charge les méthodes DELETE, GET, HEAD, PUT, POST et PATCH.
    • Des champs d'en-tête supplémentaires facultatifs, suivant l'URI et la méthode HTTP spécifiés.

  • Des champs du corps de message de demande HTTP, pour prendre en charge l'URI et l'opération HTTP. Par exemple, les opérations POST contiennent des objets codés au format MIME qui sont passés comme paramètres complexes. Pour les opérations POST ou PUT, le type de codage MIME pour le corps doit être spécifié dans l'en-tête de demande Content-type. Certains services vous obligent à utiliser un type MIME spécifique, tel que application/json.

  • Champs d'en-tête du message de réponse HTTP :

    • Un code d'état HTTP, compris entre 2xx (opérations réussies) et 4xx ou 5xx (erreur). Ou bien un code d'état défini par le service pourrait être retourné, comme indiqué dans la documentation de l'API.
    • Des champs d'en-tête supplémentaires facultatifs, nécessaires à la prise en charge de la réponse de la demande, tels qu'un en-tête de réponse Content-type.

  • Champs du corps du message de réponse HTTP facultatifs :

    • Les objets de réponse codés au format MIME sont retournés dans le corps de la réponse HTTP, par exemple une réponse à partir d'une méthode GET qui retourne des données. En règle générale, ces objets sont retournés dans un format structuré tel que JSON ou XML, comme indiqué par l'en-tête de réponse Content-type.

Documentation de l'API

Une API REST moderne exige une documentation d'API moderne. L'API REST repose sur la spécification OpenAPI (également appelée spécification swagger), et la documentation est disponible sur SwaggerHub. Au-delà de la documentation de l'API, SwaggerHub permet de générer une bibliothèque cliente dans le langage souhaité : JavaScript, TypeScript, C#, Java, Python, Ruby, entre autres.

Appels d'API test

Pour tester les messages de demande/réponse HTTP, vous pouvez recourir à l'outil Fiddler. Ce dernier est un proxy de débogage web gratuit capable d'intercepter vos demandes REST, facilitant ainsi le diagnostic des messages de demande/réponse HTTP.

Étapes suivantes

Passez en revue les API disponibles sur SwaggerHub.

Des exemples sont disponibles sur GitHub. L'exemple inclut une application HTML5 basée sur TypeScript, React et Webpack, ainsi qu'un exemple PowerShell.

D'autres questions ? Essayez de poser une question dans le forum Reporting Services