Введение
В этой статье описывается, как использовать REST API GitHub с GitHub CLI, curlили JavaScript. Краткое руководство см . в разделе AUTOTITLE.
Сведения о запросах к REST API
В этом разделе описываются элементы, составляющие запрос API:
- HTTP method (Метод HTTP)
- Путь
- Заголовки
- Типы носителей
- Аутентификация
- Параметры
Каждый запрос к REST API включает метод HTTP и путь. В зависимости от конечной точки REST API может потребоваться также указать заголовки запросов, сведения о проверке подлинности, параметры запроса или параметры текста.
Справочная документация по REST API описывает метод HTTP, путь и параметры для каждой конечной точки. В нем также отображаются примеры запросов и ответов для каждой конечной точки. Дополнительные сведения см. в справочной документации по REST.
Метод HTTP
Метод HTTP конечной точки определяет тип действия, выполняемого в заданном ресурсе. Некоторые распространенные методы HTTP: GET, POST``DELETEи PATCH. Справочная документация по REST API предоставляет метод HTTP для каждой конечной точки.
Например, http-метод для конечной точки GET"Проблемы с репозиторием списка".
По возможности REST API GitHub стремится использовать соответствующий метод HTTP для каждого действия.
GET: используется для получения ресурсов.POST: используется для создания ресурсов.PATCH: используется для обновления свойств ресурсов.PUT: используется для замены ресурсов или коллекций ресурсов.DELETE: используется для удаления ресурсов.
Путь
Каждая конечная точка имеет путь. Справочная документация по REST API предоставляет путь для каждой конечной точки. Например, путь к конечной точке /repos/{owner}/{repo}/issues"Проблемы с репозиторием списка".
Фигурные скобки {} в пути указывают параметры пути, которые необходимо указать. Параметры пути изменяют путь конечной точки и требуются в запросе. Например, параметры пути для конечной точки "Проблемы с репозиторием списка" и {repo}``{owner} . Чтобы использовать этот путь в запросе API, замените {repo} на имя репозитория, в котором вы хотите запросить список проблем, и замените {owner} именем учетной записи, принадлежащей репозиторию.
Заголовки
Заголовки предоставляют дополнительные сведения о запросе и требуемом ответе. Ниже приведены некоторые примеры заголовков, которые можно использовать в запросах к REST API GitHub. Пример запроса, использующего заголовки, см. в разделе "Создание запроса".
Accept
Большинство конечных точек REST API GitHub указывают, что следует передать Accept заголовок со значением application/vnd.github+json. Значение заголовка Accept — тип носителя. Дополнительные сведения о типах носителей см. в разделе "Типы носителей".
X-GitHub-Api-Version
Этот заголовок следует использовать для указания версии REST API, используемой для запроса. Дополнительные сведения см. в разделе Версии API.
Типы мультимедиа
Можно указать один или несколько типов носителей, добавив их в Accept заголовок запроса. Дополнительные сведения о заголовке Accept см. в разделеAccept .
Типы носителей указывают формат данных, которые требуется использовать из API. Типы мультимедиа связаны с конкретными ресурсами, что позволяет изменять их независимо друг от друга и обеспечить поддержку форматов, которые не поддерживают другие ресурсы. В документации для каждой конечной точки REST API GitHub описаны типы носителей, поддерживаемые им. Дополнительные сведения см. в разделе AUTOTITLE.
Наиболее распространенные типы носителей, поддерживаемые API REST API application/vnd.github+json application/jsonGitHub.
Существуют пользовательские типы носителей, которые можно использовать с некоторыми конечными точками. Например, REST API для управления фиксациями и [запросами на вытягивание поддерживают типы diffносителей, patchа также sha.](/rest/commits/commits#get-a-commit) Типы fullносителей , raw``textили html используются другими конечными точками.
Все пользовательские типы носителей для GitHub выглядят следующим образом: application/vnd.github.PARAM+jsonгде PARAM — имя типа носителя. Например, чтобы указать raw тип носителя, следует использовать application/vnd.github.raw+json.
Пример запроса, использующего типы носителей, см. в разделе "Создание запроса".
Проверка подлинности
Для многих конечных точек требуется проверка подлинности или возврат дополнительных сведений при проверке подлинности. Кроме того, при проверке подлинности можно выполнять больше запросов в час.
Чтобы выполнить проверку подлинности запроса, необходимо предоставить маркер проверки подлинности с необходимыми областями или разрешениями. Вы можете создать маркер personal access token, создать маркер с помощью GitHub Appили использовать встроенный GITHUB_TOKEN рабочий процесс GitHub Actions. Дополнительные сведения см. в разделе Проверка подлинности в REST API.
Пример запроса, использующего маркер проверки подлинности, см. в разделе "Выполнение запроса".
Примечание.
Если вы не хотите создать маркер, можно использовать GitHub CLI. GitHub CLI позаботится о проверке подлинности и поможет защитить учетную запись. Дополнительные сведения см. в версии GitHub CLI этой страницы.
Предупреждение
Обработайте маркер доступа так же, как и пароли или другие конфиденциальные учетные данные. Дополнительные сведения см. в разделе Обеспечение безопасности учетных данных API.
Хотя некоторые конечные точки REST API доступны без проверки подлинности, GitHub CLI требует проверки подлинности, прежде чем api использовать подкоманда для выполнения запроса API. auth login Используйте подкоманда для проверки подлинности в GitHub. Дополнительные сведения см. в разделе "Создание запроса".
Чтобы выполнить проверку подлинности запроса, необходимо предоставить маркер проверки подлинности с необходимыми областями или разрешениями. Вы можете создать маркер personal access token, создать маркер с помощью GitHub Appили использовать встроенный GITHUB_TOKEN рабочий процесс GitHub Actions. Дополнительные сведения см. в разделе Проверка подлинности в REST API.
Пример запроса, использующего маркер проверки подлинности, см. в разделе "Выполнение запроса".
Предупреждение
Обработайте маркер доступа так же, как и пароли или другие конфиденциальные учетные данные. Дополнительные сведения см. в разделе Обеспечение безопасности учетных данных API.
Параметры
Многие методы API требуют или позволяют отправлять дополнительные сведения в параметрах запроса. Существует несколько различных типов параметров: параметры пути, параметры тела и параметры запроса.
Параметры пути
Параметры пути изменяют путь конечной точки. Эти параметры необходимы в запросе. Дополнительные сведения см. в разделе "Путь".
Параметры запроса
Параметры запроса позволяют передавать дополнительные данные в API. Эти параметры могут быть необязательными или обязательными в зависимости от конечной точки. Например, параметр body может позволить указать заголовок проблемы при создании новой проблемы или указать определенные параметры при включении или отключении функции. В документации для каждой конечной точки REST API GitHub описаны параметры тела, поддерживаемые им. Дополнительные сведения см. в разделе AUTOTITLE.
Например, для конечной точки "Создание проблемы" требуется указать название новой проблемы в запросе. Кроме того, вы можете дополнительно указать другие сведения, например текст, помещенный в текст проблемы, пользователи могут назначить новую проблему или метки для применения к новой проблеме. Пример запроса, использующего параметры текста, см. в разделе "Создание запроса".
Для передачи параметров тела необходимо пройти проверку подлинности запроса. Дополнительные сведения см. в разделе "Проверка подлинности".
Параметры запроса
Параметры запроса позволяют контролировать, какие данные возвращаются для запроса. Обычно эти параметры являются необязательными. Документация для каждой конечной точки REST API GitHub будет описывать все поддерживаемые параметры запроса. Дополнительные сведения см. в разделе AUTOTITLE.
Например, конечная точка "Список общедоступных событий" возвращает тридцать проблем по умолчанию. Для возврата двух проблем вместо 30 можно использовать per_page параметр запроса. Параметр запроса можно использовать page для получения только первой страницы результатов. Пример запроса, использующего параметры запроса, см. в разделе "Создание запроса".
Выполнение запроса
В этом разделе показано, как выполнить аутентифицированный запрос к REST API GitHub с помощью GitHub CLI.
1. Настройка
Установите GitHub CLI в macOS, Windows или Linux. Дополнительные сведения см. в разделе "Установка " в репозитории GitHub CLI.
2. Проверка подлинности
-
Чтобы выполнить проверку подлинности в GitHub, выполните следующую команду из терминала.
gh auth loginВы можете использовать
--scopesэтот параметр, чтобы указать нужные области. Если вы хотите пройти проверку подлинности с помощью созданного маркера, можно использовать этот--with-tokenпараметр. Дополнительные сведения см. в документации поauth loginGitHub CLI. -
Выберите место для проверки подлинности:
- Если вы обращаетесь к GitHub по адресу GitHub.com, выберите GitHub.com.
- Если вы обращаетесь к GitHub в другом домене, выберите "Другой", а затем введите имя узла (например:
octocorp.ghe.com).
-
Следуйте остальным запросам на экране.
GitHub CLI автоматически сохраняет учетные данные Git при выборе HTTPS в качестве предпочтительного протокола для операций Git и ответить "да" запросу на запрос, хотите ли пройти проверку подлинности в Git с помощью учетных данных GitHub учетных данных. Это может быть полезно, так как это позволяет использовать такие команды Git, как
git pushиgit pullбез необходимости настраивать отдельный диспетчер учетных данных или использовать SSH.
3. Выберите конечную точку для запроса
-
Выберите конечную точку для выполнения запроса. Для обнаружения конечных точек, которые можно использовать для взаимодействия с GitHub , можно просмотреть документацию по REST API GitHub.
-
Определите метод HTTP и путь конечной точки. Вы отправите их с запросом. Дополнительные сведения см. в разделе "Метод HTTP" и "Путь".
Например, конечная точка "Создание проблемы" использует метод
POSTHTTP и путь/repos/{owner}/{repo}/issues. -
Определите все необходимые параметры пути. Требуемые параметры пути отображаются в фигурных скобках
{}в пути конечной точки. Замените заполнитель каждого параметра требуемым значением. Дополнительные сведения см. в разделе "Путь".Например, конечная точка "Создание проблемы" использует путь, а параметры пути
/repos/{owner}/{repo}/issues—{owner}и{repo}. Чтобы использовать этот путь в запросе API, замените{repo}именем репозитория, в котором вы хотите создать новую проблему, и замените{owner}именем учетной записи, которая владеет репозиторием.
4. Выполните запрос с помощью GitHub CLI
Используйте подкоманда GitHub CLI api для выполнения запроса API. Дополнительные сведения см. в документации по apiGitHub CLI.
В запросе укажите следующие параметры и значения:
-
--hostname: при проверке подлинности в нескольких учетных записях на платформах GitHub укажите место выполнения запроса. Например:
--hostname octocorp.ghe.com. -
--method , за которым следует метод HTTP и путь конечной точки. Дополнительные сведения см. в разделе "Метод HTTP" и "Путь".
-
--заголовок:
Accept: передайте тип носителя в заголовкеAccept. Чтобы передать несколько типов мультимедиа в заголовке, разделите типы носителейAcceptс запятой:Accept: application/vnd.github+json,application/vnd.github.diffДополнительные сведения см. в разделеAcceptи типах мультимедиа.X-GitHub-Api-Version: передайте версию API в заголовкеX-GitHub-Api-Version. Дополнительные сведения см. в разделеX-GitHub-Api-Version.
-
-fили-Fследуют любые параметры текста или параметры запроса вkey=valueформате.-FИспользуйте параметр для передачи параметра, который является числом, логическим значением или null.-fИспользуйте параметр для передачи параметров строки.Некоторые конечные точки используют параметры запроса, которые являются массивами. Чтобы отправить массив в строке запроса, используйте параметр запроса один раз на элемент массива и добавьте
[]после имени параметра запроса. Например, чтобы предоставить массив двух идентификаторов репозитория, используйте-f repository_ids[]=REPOSITORY_A_ID -f repository_ids[]=REPOSITORY_B_ID.Если в запросе не требуется указывать параметры текста или параметры запроса, опустите этот параметр. Дополнительные сведения см. в разделе "Параметры текста" и "Параметры запроса". Примеры см. в разделе "Пример запроса с использованием параметров текста" и "Пример запроса" с помощью параметров запроса.
-
--hostname: при проверке подлинности в нескольких учетных записях на платформах GitHub укажите место выполнения запроса. Например:
--hostname octocorp.ghe.com.
Пример запроса
В следующем примере запроса используется конечная точка Get Octocat для возврата октоката в виде искусства ASCII.
gh api --method GET /octocat \ --header 'Accept: application/vnd.github+json' \ --header "X-GitHub-Api-Version: 2022-11-28"
gh api --method GET /octocat \
--header 'Accept: application/vnd.github+json' \
--header "X-GitHub-Api-Version: 2022-11-28"
Пример запроса с помощью параметров запроса
Конечная точка "Список общедоступных событий" возвращает тридцать проблем по умолчанию. В следующем примере используется per_page параметр запроса для возврата двух проблем вместо 30, а page параметр запроса для получения только первой страницы результатов.
gh api --method GET /events -F per_page=2 -F page=1 --header 'Accept: application/vnd.github+json' \
gh api --method GET /events -F per_page=2 -F page=1
--header 'Accept: application/vnd.github+json' \
Пример запроса с использованием параметров текста
В следующем примере используется конечная точка "Создать проблему" для создания новой проблемы в репозитории a указанный репозитория.{ %ifversion ghes %} Замените REPO-NAME именем репозитория, в котором вы хотите создать новую проблему, и замените REPO-OWNER именем учетной записи, которая владеет репозиторием.{ % endif %} В ответе найдите html_url проблему и перейдите к проблеме в браузере.
gh api --method POST /repos/REPO-OWNER/REPO-NAME/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' \
gh api --method POST /repos/REPO-OWNER/REPO-NAME/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' \
В этом разделе показано, как выполнить прошедший проверку подлинности запрос к REST API curlGitHub.
1. Настройка
Необходимо установить curl на компьютере. Чтобы проверить curl , уже ли установлено, выполните команду curl --version в командной строке.
- Если выходные данные содержат сведения о версии
curl, то это означаетcurl, что устанавливается. - Если вы получите сообщение, аналогичное
command not found: curl, это означаетcurl, что оно не установлено. Загрузите и установитеcurl. Дополнительные сведения см . на странице скачивания curl.
2. Выберите конечную точку для запроса
-
Выберите конечную точку для выполнения запроса. Для обнаружения конечных точек, которые можно использовать для взаимодействия с GitHub , можно просмотреть документацию по REST API GitHub.
-
Определите метод HTTP и путь конечной точки. Вы отправите их с запросом. Дополнительные сведения см. в разделе "Метод HTTP" и "Путь".
Например, конечная точка "Создание проблемы" использует метод
POSTHTTP и путь/repos/{owner}/{repo}/issues. -
Определите все необходимые параметры пути. Требуемые параметры пути отображаются в фигурных скобках
{}в пути конечной точки. Замените заполнитель каждого параметра требуемым значением. Дополнительные сведения см. в разделе "Путь".Например, конечная точка "Создание проблемы" использует путь, а параметры пути
/repos/{owner}/{repo}/issues—{owner}и{repo}. Чтобы использовать этот путь в запросе API, замените{repo}именем репозитория, в котором вы хотите создать новую проблему, и замените{owner}именем учетной записи, которая владеет репозиторием.
3. Создание учетных данных проверки подлинности
Создайте маркер доступа для проверки подлинности запроса. Вы можете сохранить маркер и использовать его для нескольких запросов. Предоставьте маркеру любые области или разрешения, необходимые для доступа к конечной точке. Этот маркер будет отправлен в заголовке с запросом Authorization . Дополнительные сведения см. в разделе Authenticate to the Speech API (Аутентификация в API речи).
4. Создание curl запроса
Используйте команду curl для выполнения запроса. Дополнительные сведения см . в документации по curl.
Укажите следующие параметры и значения в запросе:
-
--requestили-Xзатем метод HTTP в качестве значения. Дополнительные сведения см. в статье о методе HTTP. -
--urlза которым следует полный путь в качестве значения. Полный путь — это URL-адрес, включающий базовый URL-адрес REST API GitHub (http(s)://HOSTNAME/api/v3) и пути конечной точки, как показано ниже:http(s)://HOSTNAME/api/v3/PATH.{ %ifversion ghes %} ЗаменитеHOSTNAMEименем ваш экземпляр GitHub Enterprise Server.{ % endif %} ЗаменитеPATHпуть к конечной точке. Дополнительные сведения см. в разделе "Путь".Чтобы использовать параметры запроса, добавьте его в конец пути, а затем добавьте
?имя и значение параметра запроса в формеparameter_name=value. Разделите несколько параметров запроса с помощью&. Если необходимо отправить массив в строке запроса, используйте параметр запроса один раз на элемент массива и добавьте[]его после имени параметра запроса. Например, чтобы предоставить массив двух идентификаторов репозитория, используйте?repository_ids[]=REPOSITORY_A_ID&repository_ids[]=REPOSITORY_B_ID. Дополнительные сведения см. в разделе "Параметры запроса". Пример см. в примере запроса с помощью параметров запроса. -
--headerили-H:Accept: передайте тип носителя в заголовкеAccept. Чтобы передать несколько типов мультимедиа в заголовке, разделите типы носителейAcceptзапятыми, например:Accept: application/vnd.github+json,application/vnd.github.diffДополнительные сведения см. в разделеAcceptи типах мультимедиа.X-GitHub-Api-Version: передайте версию API в заголовкеX-GitHub-Api-Version. Дополнительные сведения см. в разделеX-GitHub-Api-Version.Authorization: передайте маркер проверки подлинности в заголовкеAuthorization. Обратите внимание, что в большинстве случаев можно использоватьAuthorization: BearerилиAuthorization: tokenпередавать маркер. Однако при передаче веб-токена JSON (JWT) необходимо использоватьAuthorization: Bearer. Дополнительные сведения см. в разделе Authenticate to the Speech API (Аутентификация в API речи). Пример запроса, использующегоAuthorizationзаголовок, см . в примере запроса с использованием параметров текста.
-
--dataили-dвсе параметры тела в объекте JSON. Если в запросе не требуется указывать параметры текста, опустите этот параметр. Дополнительные сведения см. в разделе "Параметры текста". Пример запроса см. в разделе "Пример запроса с использованием параметров текста".
Пример запроса
В следующем примере запроса используется конечная точка Get Octocat для возврата октоката в виде искусства ASCII.
curl --request GET \ --url "https://api.github.com/octocat" \ --header "Accept: application/vnd.github+json" \ --header "X-GitHub-Api-Version: 2022-11-28"
curl --request GET \
--url "https://api.github.com/octocat" \
--header "Accept: application/vnd.github+json" \
--header "X-GitHub-Api-Version: 2022-11-28"
Пример запроса с помощью параметров запроса
Конечная точка "Список общедоступных событий" возвращает тридцать проблем по умолчанию. В следующем примере используется per_page параметр запроса для возврата двух проблем вместо 30, а page параметр запроса для получения только первой страницы результатов.
curl --request GET \ --url "http(s)://HOSTNAME/api/v3/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
curl --request GET \
--url "http(s)://HOSTNAME/api/v3/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
Пример запроса с использованием параметров текста
В следующем примере для создания новой проблемы в репозитории указан. %ifversion ghes %} Замените HOSTNAME именем ваш экземпляр GitHub Enterprise Server. Замените REPO-NAME именем репозитория, в котором вы хотите создать новую проблему, и замените REPO-OWNER именем учетной записи, которая владеет репозиторием.{ % endif %} Замените YOUR-TOKEN маркером проверки подлинности, созданным на предыдущем шаге.
Примечание.
Если вы используете fine-grained personal access token, необходимо заменить REPO-OWNER и REPO-NAME на репозиторий, принадлежащий или принадлежащий организации, в которую входите. Маркер должен иметь доступ к этом репозиторию и иметь разрешения на чтение и запись для проблем с репозиторием. Дополнительные сведения см. в разделе Управление личными маркерами доступа.
curl \
--request POST \
--url "http(s)://HOSTNAME/api/v3/repos/REPO-OWNER/REPO-NAME/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"
}'
curl \
--request POST \
--url "http(s)://HOSTNAME/api/v3/repos/REPO-OWNER/REPO-NAME/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"
}'
В этом разделе показано, как выполнить запрос к REST API GitHub с помощью JavaScript и Octokit.js. Более подробное руководство см. в разделе Скриптирование с помощью REST API и JavaScript.
1. Настройка
Чтобы использовать библиотеку Octokit.js, показанную в следующих примерах, необходимо установить octokit .
- Установите
octokit. Например,npm install octokit. Другие способы установки или загрузкиoctokitсм. в Octokit.js README.
2. Выберите конечную точку для запроса
-
Выберите конечную точку для выполнения запроса. Для обнаружения конечных точек, которые можно использовать для взаимодействия с GitHub , можно просмотреть документацию по REST API GitHub.
-
Определите метод HTTP и путь конечной точки. Вы отправите их с запросом. Дополнительные сведения см. в разделе "Метод HTTP" и "Путь".
Например, конечная точка "Создание проблемы" использует метод
POSTHTTP и путь/repos/{owner}/{repo}/issues. -
Определите все необходимые параметры пути. Требуемые параметры пути отображаются в фигурных скобках
{}в пути конечной точки. Замените заполнитель каждого параметра требуемым значением. Дополнительные сведения см. в разделе "Путь".Например, конечная точка "Создание проблемы" использует путь, а параметры пути
/repos/{owner}/{repo}/issues—{owner}и{repo}. Чтобы использовать этот путь в запросе API, замените{repo}именем репозитория, в котором вы хотите создать новую проблему, и замените{owner}именем учетной записи, которая владеет репозиторием.
3. Создание маркера доступа
Создайте маркер доступа для проверки подлинности запроса. Вы можете сохранить маркер и использовать его для нескольких запросов. Предоставьте маркеру любые области или разрешения, необходимые для доступа к конечной точке. Этот маркер будет отправлен в заголовке с запросом Authorization . Дополнительные сведения см. в разделе Authenticate to the Speech API (Аутентификация в API речи).
4. Создание запроса с помощью Octokit.js
-
Импортируйте
octokitв скрипт. Например,import { Octokit } from "octokit";. Другие способы импортаoctokitсм. в Octokit.js README. -
Создание экземпляра с помощью токена
Octokit.{ %ifversion ghes %} Задайте базовый URL-адресhttp(s)://HOSTNAME/api/v3. ЗаменитеHOSTNAMEименем ваш экземпляр GitHub Enterprise Server.{ % endif %} ЗаменитеYOUR-TOKENмаркером.JavaScript const octokit = new Octokit({ baseUrl: "http(s)://HOSTNAME/api/v3", auth: 'YOUR-TOKEN' });const octokit = new Octokit({ baseUrl: "http(s)://HOSTNAME/api/v3", auth: 'YOUR-TOKEN' }); -
Используйте
octokit.requestдля выполнения запроса.- Отправьте метод HTTP и путь в качестве первого аргумента в
requestметод. Дополнительные сведения см. в разделе "Метод HTTP" и "Путь". - Укажите все параметры пути, запроса и текста в объекте в качестве второго аргумента
requestметода. Дополнительные сведения см. в разделе Параметры.
В следующем примере запроса метод HTTP имеет
POSTзначение , путь —/repos/{owner}/{repo}/issuesэто параметрыowner: "REPO-OWNER"пути,repo: "REPO-NAME"а параметры тела —title: "Created with the REST API"иbody: "This is a test issue created by the REST API".{ % ifversion ghes %} ЗаменитеREPO-OWNERименем учетной записи, которая владеет репозиторием, иREPO-NAMEименем репозитория.{ % endif %}Примечание.
Если вы используете fine-grained personal access token, необходимо заменить
REPO-OWNERиREPO-NAMEна репозиторий, принадлежащий или принадлежащий организации, в которую входите. Маркер должен иметь доступ к этом репозиторию и иметь разрешения на чтение и запись для проблем с репозиторием. Дополнительные сведения см. в разделе Управление личными маркерами доступа.JavaScript await octokit.request("POST /repos/{owner}/{repo}/issues", { owner: "REPO-OWNER", repo: "REPO-NAME", title: "Created with the REST API", body: "This is a test issue created by the REST API", });await octokit.request("POST /repos/{owner}/{repo}/issues", { owner: "REPO-OWNER", repo: "REPO-NAME", title: "Created with the REST API", body: "This is a test issue created by the REST API", });Метод
requestавтоматически передаетAccept: application/vnd.github+jsonзаголовок. Чтобы передать дополнительные заголовки или другойAcceptзаголовок, добавьтеheadersсвойство в объект, передаваемый в качестве второго аргумента. Значение свойстваheaders— это объект с именами заголовков в качестве ключей и значениями заголовков в качестве значений.Например, следующий код отправляет
content-typeзаголовок со значениемtext/plainиX-GitHub-Api-Versionзаголовком со значением2022-11-28.JavaScript await octokit.request("GET /octocat", { headers: { "content-type": "text/plain", "X-GitHub-Api-Version": "2022-11-28", }, });await octokit.request("GET /octocat", { headers: { "content-type": "text/plain", "X-GitHub-Api-Version": "2022-11-28", }, }); - Отправьте метод HTTP и путь в качестве первого аргумента в
Использование ответа
После выполнения запроса API вернет код состояния ответа, заголовки ответов и потенциально текст ответа.
Сведения о коде ответа и заголовках
Каждый запрос возвращает код состояния HTTP, указывающий на успешность ответа. Дополнительные сведения о кодах ответов см. в документации по кодам состояния ответов MDN HTTP.
Кроме того, ответ будет содержать заголовки, которые предоставляют дополнительные сведения об ответе. Заголовки, начинающиеся с X- или x-, являются пользовательскими для GitHub. Например, заголовки x-ratelimit-remaining и x-ratelimit-reset сообщают, сколько запросов можно выполнить за период времени.
Чтобы просмотреть код состояния и заголовки, используйте --include или --i параметр при отправке запроса.
Например, этот запрос получает список проблем в репозитории a specified репозитория:
gh api \
--header 'Accept: application/vnd.github+json' \
--method GET /repos/REPO-OWNER/REPO-NAME/issues \
-F per_page=2 --include
И он возвращает код ответа и заголовки, которые выглядят примерно так:
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
В этом примере код ответа — 200, что указывает на успешный запрос.
При выполнении запроса с Octokit.js метод request возвращает обещание. Если запрос выполнен успешно, обещание разрешается в объект, включающий код состояния HTTP ответа (status) и заголовки ответа (headers). Если возникла ошибка, обещание разрешается в объект, включающий код состояния HTTP ответа (status) и заголовки ответа (response.headers).
При возникновении ошибки можно использовать блок try/catch для ее перехвата. Например, если запрос в следующем скрипте выполнен успешно, скрипт занесет в журнал код состояния и значение заголовка x-ratelimit-remaining. Если запрос не выполнен, скрипт занесет в журнал код состояния, значение заголовка x-ratelimit-remaining и сообщение об ошибке.
В следующем примере замените REPO-OWNER имя учетной записи, владеющей репозиторием, и REPO-NAME именем репозитория.
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}`)
}
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}`)
}
Чтобы просмотреть код состояния и заголовки, используйте --include или --i параметр при отправке запроса.
Например, этот запрос получает список проблем в репозитории a specified репозитория:
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" \
--include
И он возвращает код ответа и заголовки, которые выглядят примерно так:
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
В этом примере код ответа — 200, что указывает на успешный запрос.
Сведения о тексте ответа
Многие конечные точки возвращают текст ответа. Если не указано иное, текст ответа имеет формат JSON. Пустые поля включаются как null, а не пропускаются. Все метки времени возвращаются в формате UTC, формат ISO 8601: YYYY-MM-DDTHH:MM:SSZ
В отличие от API GraphQL, в котором вы указываете желаемую информацию, REST API обычно возвращает больше информации, чем требуется. При необходимости можно проанализировать ответ, чтобы извлечь определенные данные.
Например, можно использовать > для перенаправления ответа в файл. В следующем примере замените REPO-OWNER имя учетной записи, владеющей репозиторием, и REPO-NAME именем репозитория.
gh api \ --header 'Accept: application/vnd.github+json' \ --method GET /repos/REPO-OWNER/REPO-NAME/issues \ -F per_page=2 > data.json
gh api \
--header 'Accept: application/vnd.github+json' \
--method GET /repos/REPO-OWNER/REPO-NAME/issues \
-F per_page=2 > data.json
Затем можно использовать jq, чтобы получить заголовок и идентификатор автора каждой проблемы:
jq '.[] | {title: .title, authorID: .user.id}' data.json
jq '.[] | {title: .title, authorID: .user.id}' data.json
Две предыдущие команды возвращают примерно следующее:
{
"title": "Update index.html",
"authorID": 10701255
}
{
"title": "Edit index file",
"authorID": 53709285
}
Дополнительные сведения об jq см . в документации по jq.
Например, вы можете получить заголовок и идентификатор автора каждой проблемы. В следующем примере замените REPO-OWNER имя учетной записи, владеющей репозиторием, и REPO-NAME именем репозитория.
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}`)
}
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}`)
}
Например, можно использовать > для перенаправления ответа в файл. В следующем примере замените REPO-OWNER имя учетной записи, владеющей репозиторием, и REPO-NAME именем репозитория.{ %ifversion ghes %} Замените HOSTNAME именем ваш экземпляр GitHub Enterprise Server.{ % endif %}
curl --request GET \ --url "http(s)://HOSTNAME/api/v3/repos/REPO-OWNER/REPO-NAME/issues?per_page=2" \ --header "Accept: application/vnd.github+json" \ --header "Authorization: Bearer YOUR-TOKEN" > data.json
curl --request GET \
--url "http(s)://HOSTNAME/api/v3/repos/REPO-OWNER/REPO-NAME/issues?per_page=2" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer YOUR-TOKEN" > data.json
Затем можно использовать jq, чтобы получить заголовок и идентификатор автора каждой проблемы:
jq '.[] | {title: .title, authorID: .user.id}' data.json
jq '.[] | {title: .title, authorID: .user.id}' data.json
Две предыдущие команды возвращают примерно следующее:
{
"title": "Update index.html",
"authorID": 10701255
}
{
"title": "Edit index file",
"authorID": 53709285
}
Дополнительные сведения об jq см . в документации по jq.
Подробные и суммарные представления
Ответ может включать все атрибуты ресурса или только подмножество атрибутов в зависимости от того, извлекаете отдельный ресурс или список ресурсов.
- При получении отдельного ресурса _, например определенного _репозитория, ответ обычно будет включать все атрибуты для этого ресурса. Это "подробное" представление ресурса.
- При получении списка ресурсов, таких как список нескольких репозиториев, ответ будет включать только подмножество атрибутов для каждого ресурса. Это "сводное" представление ресурса.
Обратите внимание, что авторизация иногда влияет на объем сведений, включенных в представление.
Причина этого заключается в том, что некоторые атрибуты являются вычислительными затратами для предоставления API, поэтому GitHub исключает эти атрибуты из сводного представления. Чтобы получить эти атрибуты, можно получить подробное представление.
В документации приводится пример ответа для каждого метода API. В примере ответа показаны все атрибуты, возвращаемые этим методом.
Гиперсреда
Любой ресурс может иметь одно или несколько свойств *_url, содержащих ссылки на другие ресурсы. Они предназначены для предоставления явных URL-адресов, чтобы соответствующим клиентам API не приходилось формировать URL-адреса самостоятельно. Настоятельно рекомендуется, чтобы клиенты API использовали эти свойства. Так разработчикам будет проще обновлять API в будущем. Все URL-адреса должны соответствовать шаблонам URI RFC 6570.
Затем можно расширить эти шаблоны, например, с помощью пакета uri_template:
>> 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"
Следующие шаги
В этой статье показано, как перечислить и создать проблемы в репозитории. Попрактикуйтесь, прокомментировав проблему, изменив заголовок проблемы или закрыв проблему. Дополнительные сведения см. в разделе "Создание комментария проблемы" и конечной точки "Обновление проблемы".
Дополнительные сведения о других конечных точках, которые можно использовать, см. в справочной документации по REST.