Skip to main content

Prise en main de l’API REST

DĂ©couvrez comment utiliser l’API REST GitHub.

Introduction

Cet article explique comment utiliser l’API REST GitHub Ă  l’aide de GitHub CLI, curl ou JavaScript. Pour obtenir un guide de dĂ©marrage rapide, consultez DĂ©marrage rapide de l’API REST GitHub.

Les exemples de cet article envoient les demandes à https://api.github.com. Si vous accédez à GitHub dans un domaine différent, tel que octocorp.ghe.com, le point de terminaison des demandes d'API reflétera ce domaine. Par exemple : https://api.octocorp.ghe.com/.

À propos des demandes adressĂ©es Ă  l’API REST

Cette section dĂ©crit les Ă©lĂ©ments qui composent une demande d’API :

Chaque demande adressĂ©e Ă  l’API REST inclut une mĂ©thode HTTP et un chemin d’accĂšs. Selon le point de terminaison de l’API REST, vous devrez peut-ĂȘtre Ă©galement spĂ©cifier des en-tĂȘtes de demande, des informations d’authentification, des paramĂštres de requĂȘte ou de corps.

La documentation de rĂ©fĂ©rence de l’API REST dĂ©crit la mĂ©thode HTTP, le chemin et les paramĂštres de chaque point de terminaison. Elle prĂ©sente aussi des exemples de demande et de rĂ©ponses pour chaque point de terminaison. Pour plus d’informations, consultez la documentation de rĂ©fĂ©rence sur REST.

Méthode HTTP

La mĂ©thode HTTP d’un point de terminaison dĂ©finit le type d’action qu’il effectue sur une ressource donnĂ©e. Certaines mĂ©thodes HTTP courantes sont GET, POST, DELETE et PATCH. La documentation de rĂ©fĂ©rence de l’API REST fournit la mĂ©thode HTTP pour chaque point de terminaison.

Par exemple, la mĂ©thode HTTP pour le point de terminaison « RĂ©pertorier les problĂšmes de rĂ©fĂ©rentiel Â» est GET.

Dans la mesure du possible, l’API REST GitHub s’efforce d’utiliser une mĂ©thode HTTP appropriĂ©e pour chaque action.

  • GET : utilisĂ© pour rĂ©cupĂ©rer des ressources.
  • POST : utilisĂ© pour crĂ©er des ressources.
  • PATCH : utilisĂ© pour mettre Ă  jour les propriĂ©tĂ©s des ressources.
  • PUT : utilisĂ© pour remplacer des ressources ou des collections de celles-ci.
  • DELETE : utilisĂ© pour supprimer des ressources.

Chemin d’accùs

Chaque point de terminaison possĂšde un chemin d’accĂšs. La documentation de rĂ©fĂ©rence de l’API REST donne le chemin d’accĂšs pour chaque point de terminaison. Par exemple, le chemin d’accĂšs pour le point de terminaison « RĂ©ppertorier les problĂšmes du rĂ©fĂ©rentiel Â» est /repos/{owner}/{repo}/issues.

Les crochets courbĂ©s {} dans un chemin d’accĂšs rĂ©flĂštent des paramĂštres de chemin d’accĂšs que vous avez besoin de spĂ©cifier. Les paramĂštres de chemin d’accĂšs modifient le chemin d’accĂšs du point de terminaison et sont requis dans votre demande. Par exemple, les paramĂštres de chemin d’accĂšs pour le point de terminaison « RĂ©pertorier les problĂšmes du rĂ©fĂ©rentiel Â» sont {owner} et {repo}. Pour utiliser ce chemin d’accĂšs dans votre demande d’API, remplacez {repo} par le nom du rĂ©fĂ©rentiel dans lequel vous souhaitez demander une liste de problĂšmes, puis remplacez {owner} par le nom du compte propriĂ©taire du rĂ©fĂ©rentiel.

En-tĂȘtes

Les en-tĂȘtes fournissent des informations supplĂ©mentaires sur la demande et la rĂ©ponse souhaitĂ©e. Voici quelques exemples d’en-tĂȘtes que vous pouvez utiliser dans vos demandes pour l’API REST GitHub. Pour obtenir un exemple de demande qui utilise des en-tĂȘtes, consultez Effectuer une demande.

Accept

La plupart des points de terminaison de l’API REST GitHub spĂ©cifient que vous devez transfĂ©rer un en-tĂȘte Accept avec une valeur de application/vnd.github+json. La valeur de l’en-tĂȘte Accept est un type de mĂ©dia. Pour plus d’informations sur les types de mĂ©dias, consultez Types de mĂ©dias.

X-GitHub-Api-Version

Vous devez utiliser cet en-tĂȘte pour spĂ©cifier une version de l’API REST Ă  utiliser pour votre demande. Pour plus d’informations, consultez « Versions des API Â».

User-Agent

Toutes les demandes d’API doivent comprendre un en-tĂȘte User-Agent valide. L’en-tĂȘte User-Agent identifie l’utilisateur ou l’application qui effectue la demande.

Par dĂ©faut, GitHub CLI envoie un en-tĂȘte User-Agent valide. Toutefois, GitHub recommande d’utiliser votre nom d’utilisateur GitHub ou le nom de votre application pour la valeur d’en-tĂȘte User-Agent. Cela permet Ă  GitHub de vous contacter en cas de problĂšme.

curl envoie par dĂ©faut un en-tĂȘte User-Agent valide. Toutefois, GitHub recommande d’utiliser votre nom d’utilisateur GitHub ou le nom de votre application pour la valeur d’en-tĂȘte User-Agent. Cela permet Ă  GitHub de vous contacter en cas de problĂšme.

Si vous utilisez le Kit de dĂ©veloppement logiciel (SDK) Octokit.js, le Kit de dĂ©veloppement logiciel (SDK) envoie un en-tĂȘte valide User-Agent pour vous. Toutefois, GitHub recommande d’utiliser votre nom d’utilisateur GitHub ou le nom de votre application pour la valeur d’en-tĂȘte User-Agent. Cela permet Ă  GitHub de vous contacter en cas de problĂšme.

L’exemple suivant est un exemple User-Agent une application nommĂ©e Awesome-Octocat-App :

User-Agent: Awesome-Octocat-App

Les demandes sans en-tĂȘte User-Agent sont rejetĂ©es. Si vous fournissez un en-tĂȘte User-Agent non valide, vous recevez une rĂ©ponse 403 Forbidden.

Types de médias

Vous pouvez spĂ©cifier un ou plusieurs types de mĂ©dia en les ajoutant Ă  l’en-tĂȘte Accept de votre demande. Pour plus d’informations sur l’en-tĂȘte Accept, consultez Accept.

les types de mĂ©dia spĂ©cifient le format des donnĂ©es que vous souhaitez consommer de l’API. Les types mĂ©dias sont spĂ©cifiques aux ressources, ce qui leur permet de changer de façon indĂ©pendante et de prendre en charge des formats que d’autres ressources ne prennent pas en charge. La documentation de chaque point de terminaison de l’API REST GitHub dĂ©crit les types de mĂ©dia qu’il prend en charge. Pour plus d’informations, consultez Documentation sur l’API REST GitHub.

Les types de mĂ©dia les plus courants pris en charge par l’API REST GitHub sont application/vnd.github+json et application/json.

Il existe des types de mĂ©dia personnalisĂ©s que vous pouvez utiliser avec certains points de terminaison. Par exemple, l’API REST pour gĂ©rer validations et les demandes de tirage prennent en charge les types mĂ©dia diff, patch et sha. Les types de mĂ©dias full, raw, text, ou html sont utilisĂ©s par d'autres points de terminaison.

Tous les types de mĂ©dia personnalisĂ©s pour GitHub se prĂ©sentent comme suit : application/vnd.github.PARAM+json, oĂč PARAM est le nom du type de mĂ©dia. Par exemple, pour spĂ©cifier le type de mĂ©dia raw, vous devez utiliser application/vnd.github.raw+json.

Pour obtenir un exemple de demande qui utilise des types de média, consultez Effectuer une demande.

Authentification

De nombreux points de terminaison nĂ©cessitent une authentification ou retournent des informations supplĂ©mentaires si vous ĂȘtes authentifiĂ©. De plus, vous pouvez effectuer plus de requĂȘtes par heure lorsque vous ĂȘtes authentifiĂ©.

Pour authentifier votre demande, vous devez fournir un jeton d’authenti fication avec les Ă©tendues ou autorisations requises. Il existe plusieurs façons d’obtenir un jeton : vous pouvez crĂ©er un personal access token, gĂ©nĂ©rer un jeton avec un GitHub App, ou utiliser le GITHUB_TOKEN intĂ©grĂ© dans un flux de travail GitHub Actions. Pour plus d’informations, consultez « Authentification auprĂšs de l’API REST Â».

Pour obtenir un exemple de demande qui utilise un jeton d’authentification, consultez Effectuer une demande.

Remarque

Si vous ne souhaitez pas crĂ©er un jeton, vous pouvez utiliser GitHub CLI. GitHub CLI s’occupent de l’authentification pour vous et vous aident Ă  assurer la sĂ©curitĂ© de votre compte. Pour plus d’informations, consultez la version GitHub CLI de cette page.

Avertissement

Traitez votre jeton d’accĂšs de la mĂȘme façon que vous traitez vos mots de passe ou d’autres informations d’identification sensibles. Pour plus d’informations, consultez « SĂ©curiser les informations d’identification de l’API Â».

Bien que certains points de terminaison d’API REST soient accessibles sans authentification, GitHub CLI vous oblige à vous authentifier avant de pouvoir utiliser la sous-commande api pour effectuer une demande d’API. Utilisez la sous-commande auth login pour vous authentifier auprùs de GitHub. Pour plus d’informations, consultez Effectuer une demande.

Pour authentifier votre demande, vous devez fournir un jeton d’authenti fication avec les Ă©tendues ou autorisations requises. Il existe plusieurs façons d’obtenir un jeton : vous pouvez crĂ©er un personal access token, gĂ©nĂ©rer un jeton avec un GitHub App, ou utiliser le GITHUB_TOKEN intĂ©grĂ© dans un flux de travail GitHub Actions. Pour plus d’informations, consultez « Authentification auprĂšs de l’API REST Â».

Pour obtenir un exemple de demande qui utilise un jeton d’authentification, consultez Effectuer une demande.

Avertissement

Traitez votre jeton d’accĂšs de la mĂȘme façon que vous traitez vos mots de passe ou d’autres informations d’identification sensibles. Pour plus d’informations, consultez « SĂ©curiser les informations d’identification de l’API Â».

ParamĂštres

De nombreuses mĂ©thodes d’API nĂ©cessitent ou vous permettent d’envoyer des informations supplĂ©mentaires dans des paramĂštres dans votre demande. Il existe quelques types de paramĂštres diffĂ©rents : paramĂštres de chemin d’accĂšs, paramĂštres de corps et paramĂštres de requĂȘte.

Paramùtres de chemin d’accùs

Les paramùtres de chemin d’accùs modifient le chemin d’accùs du point de terminaison. Ces paramùtres sont requis dans votre demande. Pour plus d’informations, consultez Path.

ParamĂštres du corps

Les paramĂštres de corps vous permettent de passer des donnĂ©es supplĂ©mentaires Ă  l’API. Ces paramĂštres peuvent ĂȘtre facultatifs ou obligatoires, en fonction du point de terminaison. Par exemple, un paramĂštre de corps peut vous permettre de spĂ©cifier un titre de problĂšme pendant la crĂ©ation d’un nouveau problĂšme, ou de spĂ©cifier certains paramĂštres durant l’activation ou de la dĂ©sactivation d’une fonctionnalitĂ©. La documentation de chaque point de terminaison de l’API REST GitHub dĂ©crit les paramĂštres de corps qu’il prend en charge. Pour plus d’informations, consultez Documentation sur l’API REST GitHub.

Par exemple, le point de terminaison « CrĂ©er un problĂšme Â» vous oblige Ă  spĂ©cifier un titre pour le nouveau problĂšme dans votre demande. Il vous permet Ă©galement de spĂ©cifier Ă©ventuellement d’autres informations, telles que le texte Ă  placer dans le corps du problĂšme, les utilisateurs Ă  affecter au nouveau problĂšme ou les Ă©tiquettes Ă  appliquer au nouveau problĂšme. Pour obtenir un exemple de demande qui utilise des paramĂštres de corps, consultez Effectuer une demande.

Vous devez authentifier votre demande pour transfĂ©rer des paramĂštres de corps. Pour plus d’informations, consultez Authentification.

ParamĂštres de requĂȘte

Les paramĂštres de requĂȘte vous permettent de contrĂŽler les donnĂ©es retournĂ©es pour une requĂȘte. Ces paramĂštres sont habituellement facultatifs. La documentation de chaque point de terminaison de l’API REST GitHub dĂ©crit tout paramĂštre de requĂȘte qu’il prend en charge. Pour plus d’informations, consultez Documentation sur l’API REST GitHub.

Par exemple, le point de terminaison « RĂ©pertorier les Ă©vĂ©nements publics Â» retourne trente problĂšmes par dĂ©faut. Vous pouvez utiliser le paramĂštre de requĂȘte per_page pour renvoyer deux problĂšmes au lieu de 30. Vous pouvez utiliser le paramĂštre de requĂȘte page pour rĂ©cupĂ©rer uniquement la premiĂšre page des rĂ©sultats. Pour obtenir un exemple de demande qui utilise des paramĂštres de requĂȘte, consultez Effectuer une demande.

CrĂ©ation d’une requĂȘte

Cette section montre comment effectuer une demande authentifiĂ©e auprĂšs de l’API REST GitHub Ă  l’aide de GitHub CLI.

1. Configurer

Installez GitHub CLI sur macOS, Windows ou Linux. Pour en savoir plus, consultez Installation dans le référentiel GitHub CLI.

2. S’authentifier

  1. Pour vous authentifier sur GitHub, exécutez la commande suivante depuis votre terminal.

    gh auth login
    

    Vous pouvez utiliser l’option --scopes pour spĂ©cifier les Ă©tendues voulues. Si vous souhaitez vous authentifier avec un jeton que vous avez créé, vous pouvez utiliser l’option --with-token. Pour plus d’informations, consultez la documentation sur la sous-commande GitHub CLI auth login.

  2. SĂ©lectionnez l'endroit oĂč vous souhaitez vous authentifier :

    • Si vous accĂ©dez Ă  GitHub Ă  GitHub.com, sĂ©lectionnez GitHub.com.
    • Si vous accĂ©dez Ă  GitHub sur un autre domaine, sĂ©lectionnez Autre , puis entrez votre nom d'hĂŽte (par exemple : octocorp.ghe.com).
  3. Suivez les autres invites à l'écran.

    GitHub CLI enregistre automatiquement vos identifiants Git lorsque vous choisissez HTTPS comme protocole prĂ©fĂ©rĂ© pour les opĂ©rations Git et que vous rĂ©pondez « oui Â» Ă  l'invite vous demandant si vous souhaitez vous authentifier sur Git avec vos identifiants GitHub. Ce procĂ©dĂ© peut ĂȘtre utile car il vous permet d'utiliser les commandes Git telles que git push et git pull, sans avoir Ă  configurer un gestionnaire d'informations d'identification distinct ou Ă  utiliser SSH.

3. Choisissez un point de terminaison pour votre demande

  1. Choisissez un point de terminaison pour effectuer une demande. Vous pouvez explorer la documentation de l’API REST de GitHub pour dĂ©couvrir les points de terminaison que vous pouvez utiliser pour interagir avec GitHub.

  2. Identifiez la mĂ©thode HTTP et le chemin d’accĂšs du point de terminaison. Vous les envoyez avec votre demande. Pour plus d’informations, consultez MĂ©thode HTTP et Chemin d’accĂšs.

    Par exemple, le point de terminaison « CrĂ©er un problĂšme Â» utilise la mĂ©thode HTTP POST et le chemin d’accĂšs /repos/{owner}/{repo}/issues.

  3. Identifiez tous les paramĂštres de chemin d’accĂšs requis. Les paramĂštres de chemin d’accĂšs obligatoires apparaissent entre crochets {} dans le chemin d’accĂšs du point de terminaison. Remplacez chaque espace rĂ©servĂ© du paramĂštre par la valeur souhaitĂ©e. Pour plus d’informations, consultez Path.

    Par exemple, le point de terminaison « CrĂ©er un problĂšme Â» utilise le chemin d’accĂšs /repos/{owner}/{repo}/issues et les paramĂštres de chemin d’accĂšs sont {owner} et {repo}. Pour utiliser ce chemin d’accĂšs dans votre demande d’API, remplacez {repo} par le nom du rĂ©fĂ©rentiel dans lequel vous souhaitez crĂ©er un nouveau problĂšme, puis remplacez {owner} par le nom du compte propriĂ©taire du rĂ©fĂ©rentiel.

4. Effectuez une demande avec GitHub CLI

Pour effectuer votre demande d’API, utilisez la sous-commande api GitHub CLI. Pour plus d’informations, consultez la documentation sur la sous-commande GitHub CLI api.

Dans votre demande, spĂ©cifiez les optons et valeurs suivantes :

  • --nom d'hĂŽte : Si vous ĂȘtes authentifiĂ© sur plusieurs comptes Ă  travers les plateformes GitHub, indiquez oĂč vous faites la demande. Par exemple : --hostname octocorp.ghe.com.

  • --methode suivie de la mĂ©thode HTTP et du chemin d’accĂšs du point de terminaison. Pour plus d’informations, consultez MĂ©thode HTTP et Chemin d’accĂšs.

  • --en-tĂȘte :

    • Accept : transmettez le type de mĂ©dia dans un Accept en-tĂȘte. Pour transfĂ©rer plusieurs types de mĂ©dia dans un en-tĂȘte Accept, sĂ©parez les types de mĂ©dias par une virgule : Accept: application/vnd.github+json,application/vnd.github.diff. Pour plus d’informations, consultez Accept et Types de mĂ©dias.
    • X-GitHub-Api-Version : transmettez la version de l’API dans un X-GitHub-Api-Version en-tĂȘte. Pour plus d’informations, consultez X-GitHub-Api-Version.
  • -f ou -F suivi de tous les paramĂštres de corps ou de requĂȘte au format key=value. Utilisez l’option -F pour tranfĂ©rer un paramĂštre qui est un nombre, boolĂ©en ou nul. Utilisez l’option -f pour transfĂ©rer des paramĂštres de chaĂźne.

    Certaines points de terminaison utilisent des paramĂštres de requĂȘte qui sont des tableaux. Pour envoyer un tableau dans la chaĂźne de requĂȘte, utilisez le paramĂštre de requĂȘte une fois par Ă©lĂ©ment de tableau et ajoutez [] aprĂšs le nom du paramĂštre de requĂȘte. Par exemple, pour fournir un tableau de deux ID de rĂ©fĂ©rentiel, utilisez -f repository_ids[]=REPOSITORY_A_ID -f repository_ids[]=REPOSITORY_B_ID.

    Si vous n’avez pas besoin de spĂ©cifier de paramĂštres de corps ou de requĂȘte dans votre demande, ignorez cette option. Pour plus d’informations, consultez ParamĂštres de corps et ParamĂštres de requĂȘte. Pour obtenir des exemples, consultez Exemple de demande utilisant des paramĂštres de corps et Exemple de demande utilisant des paramĂštres de requĂȘte.

  • --nom d'hĂŽte : Si vous ĂȘtes authentifiĂ© sur plusieurs comptes Ă  travers les plateformes GitHub, indiquez oĂč vous faites la demande. Par exemple : --hostname octocorp.ghe.com.

Exemple de requĂȘte

L’exemple de demande si-aprĂšs utilise le point de terminaison « Obtenir l’octocat Â» pour renvoyer l’octocat en tant qu’art ASCII.

Shell
gh api --method GET /octocat \
--header 'Accept: application/vnd.github+json' \
--header "X-GitHub-Api-Version: 2022-11-28"

Exemple de dmande utilisant des paramĂštres de requĂȘte

Le point de terminaison « RĂ©pertorier les Ă©vĂ©nements publics Â» retourne trente problĂšmes par dĂ©faut. L’exemple suivant utilise le paramĂštre de requĂȘte per_page pour renvoyer deux problĂšmes au lieu de 30, et le paramĂštre de requĂȘte page pour rĂ©cupĂ©rer uniquement la premiĂšre page des rĂ©sultats.

Shell
gh api --method GET /events -F per_page=2 -F page=1
--header 'Accept: application/vnd.github+json' \

Exemple de demande utilisant des paramĂštres de corps

L’exemple suivant utilise le point de terminaison « CrĂ©er un problĂšme Â» pour crĂ©er un nouveau problĂšme dans le rĂ©fĂ©rentiel octocat/Couteau Ă  cuillĂšre. Dans la rĂ©ponse, recherchez le html_url de votre problĂšme et accĂ©dez Ă  votre problĂšme dans le navigateur.

Shell
gh api --method POST /repos/octocat/Spoon-Knife/issues \
--header "Accept: application/vnd.github+json" \
--header "X-GitHub-Api-Version: 2022-11-28" \
-f title='Created with the REST API' \
-f body='This is a test issue created by the REST API' \

Cette section montre comment effectuer une demande authentifiĂ©e auprĂšs de l’API REST GitHub Ă  l’aide curl.

1. Configurer

Vous devez disposer de curl installé sur votre ordinateur. Pour vérifier si curl est déjà installé, exécutez curl --version sur la ligne de commande.

  • Si la sortie fournit des informations sur la version de curl, cela signifie que curl est installĂ©.
  • Si vous recevez un message similaire Ă  command not found: curl, cela signifie que curl n’est pas installĂ©. TĂ©lĂ©chargez et installez curl. Pour plus d’informations, consultez la page de tĂ©lĂ©chargement de boucle.

2. Choisissez un point de terminaison pour votre demande

  1. Choisissez un point de terminaison pour effectuer une demande. Vous pouvez explorer la documentation de l’API REST de GitHub pour dĂ©couvrir les points de terminaison que vous pouvez utiliser pour interagir avec GitHub.

  2. Identifiez la mĂ©thode HTTP et le chemin d’accĂšs du point de terminaison. Vous les envoyez avec votre demande. Pour plus d’informations, consultez MĂ©thode HTTP et Chemin d’accĂšs.

    Par exemple, le point de terminaison « CrĂ©er un problĂšme Â» utilise la mĂ©thode HTTP POST et le chemin d’accĂšs /repos/{owner}/{repo}/issues.

  3. Identifiez tous les paramĂštres de chemin d’accĂšs requis. Les paramĂštres de chemin d’accĂšs obligatoires apparaissent entre crochets {} dans le chemin d’accĂšs du point de terminaison. Remplacez chaque espace rĂ©servĂ© du paramĂštre par la valeur souhaitĂ©e. Pour plus d’informations, consultez Path.

    Par exemple, le point de terminaison « CrĂ©er un problĂšme Â» utilise le chemin d’accĂšs /repos/{owner}/{repo}/issues et les paramĂštres de chemin d’accĂšs sont {owner} et {repo}. Pour utiliser ce chemin d’accĂšs dans votre demande d’API, remplacez {repo} par le nom du rĂ©fĂ©rentiel dans lequel vous souhaitez crĂ©er un nouveau problĂšme, puis remplacez {owner} par le nom du compte propriĂ©taire du rĂ©fĂ©rentiel.

3. CrĂ©ez des informations d’identification d’authentification

CrĂ©ez un jeton d’accĂšs pour authentifier votre demande. Vous pouvez enregistrer votre jeton et l’utiliser pour plusieurs demandes. Donnez au jeton toutes les Ă©tendues ou autorisations requises pour accĂ©der au point de terminaison. Vous enverrez ce jeton dans un en-tĂȘte Authorization avec votre demande. Pour en savoir plus, consultez Authentification.

4. Effectuez une demande curl

Utilisez la commande curl pour effectuer votre requĂȘte. Pour plus d’informations, consultez la documentation de boucle.

SpĂ©cifiez les options et valeurs suivantes dans votre demande :

  • --request ou -X suivi de la mĂ©thode HTTP en tant que valeur. Pour plus d'informations, consultez MĂ©thode HTTP.

  • --url suivi du chemin complet comme valeur. Le chemin complet est une URL qui comprend l'URL de base de l'API REST de GitHub (https://api.github.com ou https://api.SUBDOMAIN.ghe.com, selon l'endroit oĂč vous accĂ©dez GitHub) et le chemin du point de terminaison, comme ceci : https://api.github.com/PATH. Remplacer par le chemin d'accĂšs au point de terminaison. Pour plus d’informations, consultez Path.

    Pour utiliser les paramĂštres de requĂȘte, ajoutez un ? Ă  la fin du chemin d’accĂšs, puis ajoutez le nom et la valeur de votre paramĂštre de requĂȘte dans le formulaire parameter_name=value. SĂ©parez les paramĂštres de requĂȘte, quand il y en a plusieurs, par un &. Si vous souhaitez envoyer un tableau dans la chaĂźne de requĂȘte, utilisez le paramĂštre de requĂȘte une fois par Ă©lĂ©ment de tableau et ajoutez [] aprĂšs le nom du paramĂštre de requĂȘte. Par exemple, pour fournir un tableau de deux ID de rĂ©fĂ©rentiel, utilisez ?repository_ids[]=REPOSITORY_A_ID&repository_ids[]=REPOSITORY_B_ID. Pour en savoir plus, consultez ParamĂštres des requĂȘtes. Pour obtenir un exemple, consultez Exemple de demande utilisant des paramĂštres de requĂȘte.

  • --header ou -H :

    • Accept : transmettez le type de mĂ©dia dans un Accept en-tĂȘte. Pour transfĂ©rer plusieurs types de mĂ©dia dans un en-tĂȘte Accept, sĂ©parez les types de mĂ©dia par une virgule, par exemple : Accept: application/vnd.github+json,application/vnd.github.diff. Pour plus d’informations, consultez Accept et Types de mĂ©dias.
    • X-GitHub-Api-Version : transmettez la version de l’API dans un X-GitHub-Api-Version en-tĂȘte. Pour plus d’informations, consultez X-GitHub-Api-Version.
    • Authorization : transmettez votre jeton d’authentification dans un Authorization en-tĂȘte. Sachez que dans la plupart des cas, vous pouvez utiliser Authorization: Bearer ou Authorization: token pour tranfĂ©rer un jeton. Toutefois, si vous passez un jeton web JSON (JWT), vous devez utiliser Authorization: Bearer. Pour en savoir plus, consultez Authentification. Pour obtenir un exemple de demande qui utilise un en-tĂȘte Authorization, consultez Exemple de demande utilisant des paramĂštres de corps.
  • --data ou -d suivi de tous les paramĂštres de corps au sein d’un objet JSON. Si vous ne souhaitez pas spĂ©cifier de paramĂštres de corps dans votre demande, ignorez cette option. Pour plus d’informations, consultez ParamĂštres de corps. Pour obtenir un exemple, consultez Exemple de demande utilisant des paramĂštres de corps.

Exemple de requĂȘte

L’exemple de demande si-aprĂšs utilise le point de terminaison « Obtenir l’octocat Â» pour renvoyer l’octocat en tant qu’art ASCII.

Shell
curl --request GET \
--url "https://api.github.com/octocat" \
--header "Accept: application/vnd.github+json" \
--header "X-GitHub-Api-Version: 2022-11-28"

Exemple de dmande utilisant des paramĂštres de requĂȘte

Le point de terminaison « RĂ©pertorier les Ă©vĂ©nements publics Â» retourne trente problĂšmes par dĂ©faut. L’exemple suivant utilise le paramĂštre de requĂȘte per_page pour renvoyer deux problĂšmes au lieu de 30, et le paramĂštre de requĂȘte page pour rĂ©cupĂ©rer uniquement la premiĂšre page des rĂ©sultats.

Shell
curl --request GET \
--url "https://api.github.com/events?per_page=2&page=1" \
--header "Accept: application/vnd.github+json" \
--header "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/events

Exemple de demande utilisant des paramĂštres de corps

L’exemple suivant utilise le point de terminaison CrĂ©er un problĂšme pour crĂ©er un nouveau problĂšme dans le rĂ©fĂ©rentiel octocat/Spoon-Knife. Remplacez YOUR-TOKEN par le jeton d’authentification que vous avez créé Ă  l’étape prĂ©cĂ©dente.

Remarque

Si vous utilisez un fine-grained personal access token, vous devez remplacer octocat/Spoon-Knife par un rĂ©fĂ©rentiel qui vous appartient ou qui appartient Ă  une organisation dont vous ĂȘtes membre. Votre jeton doit avoir accĂšs Ă  ce dĂ©pĂŽt et avoir des autorisations en lecture et Ă©criture pour les problĂšmes de dĂ©pĂŽt. Pour plus d’informations, consultez « Gestion de vos jetons d'accĂšs personnels Â».

Shell
curl \
--request POST \
--url "https://api.github.com/repos/octocat/Spoon-Knife/issues" \
--header "Accept: application/vnd.github+json" \
--header "X-GitHub-Api-Version: 2022-11-28" \
--header "Authorization: Bearer YOUR-TOKEN" \
--data '{
  "title": "Created with the REST API",
  "body": "This is a test issue created by the REST API"
}'

Cette section montre comment effectuer une demande Ă  l’API REST GitHub Ă  l’aide de JavaScript et Octokit.js. Pour obtenir un guide plus dĂ©taillĂ©, consultez Écriture de scripts avec l’API REST et JavaScript.

1. Configurer

Vous devez installer octokit pour utiliser la bibliothÚque Octokit.js illustrée dans les exemples suivants.

2. Choisissez un point de terminaison pour votre demande

  1. Choisissez un point de terminaison pour effectuer une demande. Vous pouvez explorer la documentation de l’API REST de GitHub pour dĂ©couvrir les points de terminaison que vous pouvez utiliser pour interagir avec GitHub.

  2. Identifiez la mĂ©thode HTTP et le chemin d’accĂšs du point de terminaison. Vous les envoyez avec votre demande. Pour plus d’informations, consultez MĂ©thode HTTP et Chemin d’accĂšs.

    Par exemple, le point de terminaison « CrĂ©er un problĂšme Â» utilise la mĂ©thode HTTP POST et le chemin d’accĂšs /repos/{owner}/{repo}/issues.

  3. Identifiez tous les paramĂštres de chemin d’accĂšs requis. Les paramĂštres de chemin d’accĂšs obligatoires apparaissent entre crochets {} dans le chemin d’accĂšs du point de terminaison. Remplacez chaque espace rĂ©servĂ© du paramĂštre par la valeur souhaitĂ©e. Pour plus d’informations, consultez Path.

    Par exemple, le point de terminaison « CrĂ©er un problĂšme Â» utilise le chemin d’accĂšs /repos/{owner}/{repo}/issues et les paramĂštres de chemin d’accĂšs sont {owner} et {repo}. Pour utiliser ce chemin d’accĂšs dans votre demande d’API, remplacez {repo} par le nom du rĂ©fĂ©rentiel dans lequel vous souhaitez crĂ©er un nouveau problĂšme, puis remplacez {owner} par le nom du compte propriĂ©taire du rĂ©fĂ©rentiel.

3. CrĂ©ez un jeton d’accĂšs

CrĂ©ez un jeton d’accĂšs pour authentifier votre demande. Vous pouvez enregistrer votre jeton et l’utiliser pour plusieurs demandes. Donnez au jeton toutes les Ă©tendues ou autorisations requises pour accĂ©der au point de terminaison. Vous enverrez ce jeton dans un en-tĂȘte Authorization avec votre demande. Pour en savoir plus, consultez Authentification.

4. Effectuez une demande avec Octokit.js

  1. Importez octokit dans votre script. Par exemple : import { Octokit } from "octokit";. Pour dĂ©couvrir d’autres maniĂšres d’importer octokit, consultez le fichier Lisez-moi d’Octokit.js.

  2. Créez une instance de Octokit avec votre jeton. Remplacez YOUR-TOKEN par votre jeton.

    JavaScript
    const octokit = new Octokit({ 
      auth: 'YOUR-TOKEN'
    });
    
  3. Utilisez octokit.request pour exĂ©cuter votre requĂȘte.

    • Envoyez la mĂ©thode HTTP et le chemin d’accĂšs en tant que premier argument Ă  la mĂ©thode request. Pour plus d’informations, consultez MĂ©thode HTTP et Chemin d’accĂšs.
    • SpĂ©cifiez tous les paramĂštres de chemin d’accĂšs, de requĂȘte et de corps dans un objet en tant que second argument Ă  la mĂ©thode request. Pour plus d’informations, consultez ParamĂštres.

    Dans l’exemple de demande suivant, la mĂ©thode HTTP est POST, le chemin d’accĂšs est /repos/{owner}/{repo}/issues, les paramĂštres de chemin d’accĂšs sont owner: "octocat" et repo: "Spoon-Knife", et les paramĂštres de corps sont title: "Created with the REST API" et body: "This is a test issue created by the REST API".

    Remarque

    Si vous utilisez un fine-grained personal access token, vous devez remplacer octocat/Spoon-Knife par un rĂ©fĂ©rentiel qui vous appartient ou qui appartient Ă  une organisation dont vous ĂȘtes membre. Votre jeton doit avoir accĂšs Ă  ce dĂ©pĂŽt et avoir des autorisations en lecture et Ă©criture pour les problĂšmes de dĂ©pĂŽt. Pour plus d’informations, consultez « Gestion de vos jetons d'accĂšs personnels Â».

    JavaScript
    await octokit.request("POST /repos/{owner}/{repo}/issues", {
      owner: "octocat",
      repo: "Spoon-Knife",
      title: "Created with the REST API",
      body: "This is a test issue created by the REST API",
    });
    

    La mĂ©thode request passe automatiquement l’en-tĂȘte Accept: application/vnd.github+json. Pour passer des en-tĂȘtes supplĂ©mentaires ou un en-tĂȘte Accept diffĂ©rent, ajoutez une propriĂ©tĂ© headers Ă  l’objet passĂ© en tant que deuxiĂšme argument. La valeur de la propriĂ©tĂ© headers est un objet avec les noms d’en-tĂȘte en tant que clĂ©s et les valeurs d’en-tĂȘte en tant que valeurs.

    Par exemple, le code ci-aprĂšs envoie un en-tĂȘte content-type avec la valeur de text/plain et un en-tĂȘte X-GitHub-Api-Version avec la valeur de 2022-11-28.

    JavaScript
    await octokit.request("GET /octocat", {
      headers: {
        "content-type": "text/plain",
        "X-GitHub-Api-Version": "2022-11-28",
      },
    });
    

Utilisation de la réponse

aprĂšs avoir effectuer une demande, l’API retourne le code d’état de la rĂ©ponse, les en-tĂȘtes de rĂ©ponse et Ă©ventuellement un corps de rĂ©ponse.

À propos du code et des en-tĂȘtes de rĂ©ponse

Chaque requĂȘte retourne un code d’état HTTP qui indique la rĂ©ussite de la rĂ©ponse. Pour plus d’informations sur les codes de rĂ©ponse, consultez la documentation relative aux codes d’état de la rĂ©ponse HTTP MDN.

De plus, la rĂ©ponse inclut des en-tĂȘtes qui fournissent d’autres dĂ©tails. Les en-tĂȘtes qui commencent par X- ou x- sont propres Ă  GitHub. Par exemple, les en-tĂȘtes x-ratelimit-remaining et x-ratelimit-reset vous indiquent le nombre de requĂȘtes que vous pouvez effectuer pendant une pĂ©riode donnĂ©e.

Pour visualiser le code d’état et les en-tĂȘtes, utilisez l’option --include ou --i quand vous envoyez votre demande.

Par exemple, cette demande obtient une liste de problĂšmes dans le rĂ©fĂ©rentiel octocat/Couteau Ă  cuillĂšre :

gh api \
--header 'Accept: application/vnd.github+json' \
--method GET /repos/octocat/Spoon-Knife/issues \
-F per_page=2 --include

Et elle retourne un code de rĂ©ponse et des en-tĂȘtes qui ressemblent Ă  ceci :

HTTP/2.0 200 OK
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
Cache-Control: private, max-age=60, s-maxage=60
Content-Security-Policy: default-src 'none'
Content-Type: application/json; charset=utf-8
Date: Thu, 04 Aug 2022 19:56:41 GMT
Etag: W/"a63dfbcfdb73621e9d2e89551edcf9856731ced534bd7f1e114a5da1f5f73418"
Link: <https://api.github.com/repositories/1300192/issues?per_page=1&page=2>; rel="next", <https://api.github.com/repositories/1300192/issues?per_page=1&page=14817>; rel="last"
Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
Server: GitHub.com
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
Vary: Accept, Authorization, Cookie, Accept-Encoding, Accept, X-Requested-With
X-Accepted-Oauth-Scopes: repo
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-Github-Api-Version-Selected: 2022-08-09
X-Github-Media-Type: github.v3; format=json
X-Github-Request-Id: 1C73:26D4:E2E500:1EF78F4:62EC2479
X-Oauth-Client-Id: 178c6fc778ccc68e1d6a
X-Oauth-Scopes: gist, read:org, repo, workflow
X-Ratelimit-Limit: 15000
X-Ratelimit-Remaining: 14996
X-Ratelimit-Reset: 1659645499
X-Ratelimit-Resource: core
X-Ratelimit-Used: 4
X-Xss-Protection: 0

Dans cet exemple, le code de rĂ©ponse est 200, ce qui indique que la requĂȘte est rĂ©ussie.

Quand vous effectuez une requĂȘte avec Octokit.js, la mĂ©thode request retourne une promesse. Si la requĂȘte rĂ©ussit, la promesse est rĂ©solue en objet qui inclut le code d’état HTTP de la rĂ©ponse (status) et les en-tĂȘtes de rĂ©ponse (headers). Si une erreur se produit, la promesse est rĂ©solue en objet qui inclut le code d’état HTTP de la rĂ©ponse (status) et les en-tĂȘtes de rĂ©ponse (response.headers).

Vous pouvez utiliser un bloc try/catch pour intercepter une erreur Ă©ventuelle. Par exemple, si la requĂȘte indiquĂ©e dans le script suivant rĂ©ussit, le script journalise le code d’état et la valeur de l’en-tĂȘte x-ratelimit-remaining. Si la requĂȘte Ă©choue, le script journalise le code d’état, la valeur de l’en-tĂȘte x-ratelimit-remaining et le message d’erreur.

Dans l’exemple suivant, remplacez REPO-OWNER par le nom du compte propriĂ©taire du rĂ©fĂ©rentiel et REPO-NAME par le nom du rĂ©fĂ©rentiel.

JavaScript
try {
  const result = await octokit.request("GET /repos/{owner}/{repo}/issues", {
    owner: "REPO-OWNER",
    repo: "REPO-NAME",
    per_page: 2,
  });

  console.log(`Success! Status: ${result.status}. Rate limit remaining: ${result.headers["x-ratelimit-remaining"]}`)

} catch (error) {
  console.log(`Error! Status: ${error.status}. Rate limit remaining: ${error.headers["x-ratelimit-remaining"]}. Message: ${error.response.data.message}`)
}

Pour visualiser le code d’état et les en-tĂȘtes, utilisez l’option --include ou --i quand vous envoyez votre demande.

Par exemple, cette demande obtient une liste de problĂšmes dans le rĂ©fĂ©rentiel octocat/Couteau Ă  cuillĂšre :

curl --request GET \
--url "https://api.github.com/repos/octocat/Spoon-Knife/issues?per_page=2" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer YOUR-TOKEN" \
--include

Et elle retourne un code de rĂ©ponse et des en-tĂȘtes qui ressemblent Ă  ceci :

HTTP/2 200
server: GitHub.com
date: Thu, 04 Aug 2022 20:07:51 GMT
content-type: application/json; charset=utf-8
cache-control: public, max-age=60, s-maxage=60
vary: Accept, Accept-Encoding, Accept, X-Requested-With
etag: W/"7fceb7e8c958d3ec4d02524b042578dcc7b282192e6c939070f4a70390962e18"
x-github-media-type: github.v3; format=json
link: <https://api.github.com/repositories/1300192/issues?per_page=2&sort=updated&direction=asc&page=2>; rel="next", <https://api.github.com/repositories/1300192/issues?per_page=2&sort=updated&direction=asc&page=7409>; rel="last"
access-control-expose-headers: ETag, Link, Location, Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
access-control-allow-origin: *
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
content-security-policy: default-src 'none'
x-ratelimit-limit: 15000
x-ratelimit-remaining: 14996
x-ratelimit-reset: 1659645535
x-ratelimit-resource: core
x-ratelimit-used: 4
accept-ranges: bytes
content-length: 4936
x-github-request-id: 14E0:4BC6:F1B8BA:208E317:62EC2715

Dans cet exemple, le code de rĂ©ponse est 200, ce qui indique que la requĂȘte est rĂ©ussie.

À propos du corps de rĂ©ponse

De nombreux points de terminaison retournent un corps de rĂ©ponse. Sauf indication contraire, le corps de rĂ©ponse est au format JSON. Les champs vierges sont inclus comme null au lieu d’ĂȘtre omis. Tous les horodateurs reviennent en temps UTC, format ISO 8601 : YYYY-MM-DDTHH:MM:SSZ.

Contrairement Ă  l’API GraphQL oĂč vous spĂ©cifiez les informations que vous voulez, l’API REST renvoie gĂ©nĂ©ralement plus d’informations que nĂ©cessaire. Si vous le voulez, vous pouvez analyser la rĂ©ponse pour extraire des Ă©lĂ©ments spĂ©cifiques d’informations.

Par exemple, vous pouvez utiliser > pour rediriger la rĂ©ponse vers un fichier. Dans l’exemple suivant, remplacez REPO-OWNER par le nom du compte propriĂ©taire du rĂ©fĂ©rentiel et REPO-NAME par le nom du rĂ©fĂ©rentiel.

Shell
gh api \
--header 'Accept: application/vnd.github+json' \
--method GET /repos/REPO-OWNER/REPO-NAME/issues \
-F per_page=2 > data.json

Vous pouvez ensuite utiliser jq pour obtenir le titre et l’ID d’auteur de chaque problĂšme :

Shell
jq '.[] | {title: .title, authorID: .user.id}' data.json

Les deux commandes prĂ©cĂ©dentes retournent quelque chose comme ceci :

{
  "title": "Update index.html",
  "authorID": 10701255
}
{
  "title": "Edit index file",
  "authorID": 53709285
}

Pour plus d’informations sur jq, consultez la documentation de jq.

Par exemple, vous pouvez obtenir le titre et l’ID d’auteur de chaque problĂšme. Dans l’exemple suivant, remplacez REPO-OWNER par le nom du compte propriĂ©taire du rĂ©fĂ©rentiel et REPO-NAME par le nom du rĂ©fĂ©rentiel.

JavaScript
try {
  const result = await octokit.request("GET /repos/{owner}/{repo}/issues", {
    owner: "REPO-OWNER",
    repo: "REPO-NAME",
    per_page: 2,
  });

  const titleAndAuthor = result.data.map(issue => {title: issue.title, authorID: issue.user.id})

  console.log(titleAndAuthor)

} catch (error) {
  console.log(`Error! Status: ${error.status}. Message: ${error.response.data.message}`)
}

Par exemple, vous pouvez utiliser > pour rediriger la rĂ©ponse vers un fichier. Dans l’exemple suivant, remplacez REPO-OWNER par le nom du compte propriĂ©taire du rĂ©fĂ©rentiel et REPO-NAME par le nom du rĂ©fĂ©rentiel.

Shell
curl --request GET \
--url "https://api.github.com/repos/REPO-OWNER/REPO-NAME/issues?per_page=2" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer YOUR-TOKEN" > data.json

Vous pouvez ensuite utiliser jq pour obtenir le titre et l’ID d’auteur de chaque problĂšme :

Shell
jq '.[] | {title: .title, authorID: .user.id}' data.json

Les deux commandes prĂ©cĂ©dentes retournent quelque chose comme ceci :

{
  "title": "Update index.html",
  "authorID": 10701255
}
{
  "title": "Edit index file",
  "authorID": 53709285
}

Pour plus d’informations sur jq, consultez la documentation de jq.

Représentations détaillées ou résumées

Une rĂ©ponse peut comprendre tous les attributs d’une ressource ou seulement un sous-ensemble d’attributs, selon que vous rĂ©cupĂ©rez une ressource individuelle ou une liste de ressources.

  • Quand vous rĂ©cupĂ©rez une ressource individuelle, notamment un rĂ©fĂ©rentiel spĂ©cifique, la rĂ©ponse comprend gĂ©nĂ©ralement tous les attributs de cette ressource. Il s’agit de la reprĂ©sentation « dĂ©taillĂ©e » de la ressource.
  • Quand vous rĂ©cupĂ©rez une liste de ressources, comme une liste de plusieurs rĂ©fĂ©rentiels, la rĂ©ponse comprend uniquement un sous-ensemble des attributs pour chaque ressource. Il s’agit de la reprĂ©sentation « rĂ©capitulative » de la ressource.

Sachez que l’autorisation influe parfois sur quantitĂ© de dĂ©tail comprise dans la reprĂ©sentation.

La raison en est que certains attributs sont coĂ»teux en calcul pour l’API,, donc GitHub exclut ces attributs de la reprĂ©sentation de rĂ©sumĂ©. POur obtenir ces attributs, vous pouvez rĂ©cupĂ©rez la reprĂ©sentation dĂ©taillĂ©e.

La documentation fournit un exemple de rĂ©ponse pour chaque mĂ©thode d’API. L’exemple de rĂ©ponse illustre tous les attributs retournĂ©s par cette mĂ©thode.

Hypermédia

Toutes les ressources peuvent comporter une ou plusieurs propriĂ©tĂ©s *_url liĂ©es Ă  d’autres ressources. Ces propriĂ©tĂ©s visent Ă  fournir des URL explicites afin d’éviter aux clients d’API appropriĂ©s d’avoir Ă  construire des URL eux-mĂȘmes. Il est vivement recommandĂ© aux clients d’API de les utiliser. Cela facilite les mises Ă  niveau futures de l’API pour les dĂ©veloppeurs. Toutes les URL doivent reprĂ©senter des modĂšles d’URI RFC 6570 appropriĂ©s.

Vous pouvez ensuite dĂ©velopper ces modĂšles Ă  l’aide de la gemme uri_template ou d’un objet similaire :

>> tmpl = URITemplate.new('/notifications{?since,all,participating}')
>> tmpl.expand
=> "/notifications"

>> tmpl.expand all: 1
=> "/notifications?all=1"

>> tmpl.expand all: 1, participating: 1
=> "/notifications?all=1&participating=1"

Étapes suivantes

Cet article a montrĂ© comment lister et crĂ©er des problĂšmes dans un dĂ©pĂŽt. En guise de pratique, essayez de commenter un problĂšme, d’en modifier le titre ou de le fermer. Pour plus d’informations, consultez un point de terminaison « CrĂ©er un commentaire de problĂšme Â» et le point de terminaison « Mettre Ă  jour un problĂšme Â».

Pour plus d’informations sur d’autres points de terminaison que vous pouvez utiliser, consultez la documentation de rĂ©fĂ©rence REST.