REST API 요청 만들기
비율 제한
응답 형식
인증
요청 요구 사항
Evaluating a response
- null vs false
- Redirects
페이지 매김

REST API

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

GitLab REST API를 사용하여 호환 가능한 REST API 클라이언트를 사용하여 데이터를 검색하세요.

REST API 버전은 의미론적 버전 지정 규격을 준수합니다. 주요 버전 번호는 4입니다.

하위 호환되지 않는 변경 사항은 이 버전 번호를 변경해야 합니다.

하위 버전은 명시적이지 않으며, 안정적인 API 엔드포인트를 허용합니다.
새로운 기능은 동일한 버전 번호에 추가됩니다.
주요 API 버전 변경 및 전체 API 버전 제거는 주요 GitLab 릴리스와 함께 진행됩니다.
모든 사용 중단 및 버전 간의 변경 사항은 문서에 기록됩니다.

다음은 사용 중단 프로세스에서 제외되며 언제든지 통보 없이 제거될 수 있습니다:

실험적 또는 베타로 표시된 REST API 리소스의 요소들.
기능 플래그 뒤에 숨어 있으며 기본적으로 비활성화된 필드.

REST API 요청 만들기

REST API 요청을 하려면:

REST API 클라이언트를 사용하여 API 엔드포인트에 요청을 제출하세요.
GitLab 인스턴스가 요청에 응답합니다. 상태 코드와 해당되는 경우 요청된 데이터를 반환합니다. 상태 코드는 요청의 결과를 나타내며 문제 해결 시 유용합니다.

REST API 요청은 루트 엔드포인트와 경로로 시작해야 합니다.

루트 엔드포인트는 GitLab 호스트 이름입니다.
경로는 /api/v4로 시작해야 합니다(v4는 API 버전을 나타냅니다).

다음 예제에서 API 요청은 GitLab 호스트 example.com에서 모든 프로젝트 목록을 검색합니다:

curl "https://example.com/api/v4/projects"

일부 엔드포인트에 액세스하려면 인증이 필요합니다. 자세한 내용은 인증을 참조하세요.

비율 제한

REST API 요청은 비율 제한 설정의 적용을 받습니다. 이러한 설정은 GitLab 인스턴스가 과부하되는 위험을 줄입니다.

자세한 내용은 비율 제한을 참조하세요.
GitLab.com에서 사용된 비율 제한 설정에 대한 자세한 내용은 GitLab.com 특정 비율 제한을 참조하세요.

응답 형식

REST API 응답은 JSON 형식으로 반환됩니다. 일부 API 엔드포인트는 일반 텍스트 형식을 지원합니다. 엔드포인트가 어떤 콘텐츠 유형을 지원하는지 확인하려면 REST API 리소스를 참조하세요.

인증

대부분의 API 요청은 인증이 필요하며, 인증이 제공되지 않을 경우 공개 데이터만 반환됩니다. 인증이 필요하지 않은 경우 각 엔드포인트의 문서에 이 사항이 명시되어 있습니다. 예를 들어, /projects/:id 엔드포인트는 인증이 필요하지 않습니다.

다음과 같은 여러 가지 방법으로 GitLab API에 인증할 수 있습니다:

프로젝트 액세스 토큰은 다음에서 지원됩니다:

Self-managed GitLab: Free, Premium, 및 Ultimate.
GitLab SaaS: Premium 및 Ultimate.

관리자라면, 귀하 또는 귀하의 애플리케이션은 다음을 사용하여 특정 사용자로 인증할 수 있습니다:

임시 토큰
Sudo

인증 정보가 유효하지 않거나 누락된 경우 GitLab은 상태 코드 401과 함께 오류 메시지를 반환합니다:

{
  "message": "401 Unauthorized"
}

배포 토큰은 GitLab 공개 API와 함께 사용할 수 없습니다. 자세한 내용은 배포 토큰을 참조하세요.

OAuth 2.0 토큰

API와 인증하기 위해 OAuth 2.0 토큰을 사용하여 access_token 매개변수나 Authorization 헤더에 전달할 수 있습니다.

매개변수에서 OAuth 2.0 토큰을 사용하는 예:

curl "https://gitlab.example.com/api/v4/projects?access_token=OAUTH-TOKEN"

헤더에서 OAuth 2.0 토큰을 사용하는 예:

curl --header "Authorization: Bearer OAUTH-TOKEN" "https://gitlab.example.com/api/v4/projects"

OAuth 2.0 공급자로서의 GitLab에 대해 더 알아보세요.

모든 OAuth 액세스 토큰은 생성 후 2시간 동안 유효합니다. refresh_token 매개변수를 사용하여 토큰을 갱신할 수 있습니다. 새 액세스 토큰을 새로 고침 토큰을 사용하여 요청하는 방법은 OAuth 2.0 토큰 문서를 참조하세요.

개인/프로젝트/그룹 액세스 토큰

API와 인증하기 위해 액세스 토큰을 사용하여 private_token 매개변수나 PRIVATE-TOKEN 헤더에 전달할 수 있습니다.

개인, 프로젝트 또는 그룹 액세스 토큰을 매개변수에서 사용하는 예:

curl "https://gitlab.example.com/api/v4/projects?private_token=<your_access_token>"

개인, 프로젝트 또는 그룹 액세스 토큰을 헤더에서 사용하는 예:

curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects"

또한 개인, 프로젝트 또는 그룹 액세스 토큰을 OAuth 호환 헤더와 함께 사용할 수 있습니다:

curl --header "Authorization: Bearer <your_access_token>" "https://gitlab.example.com/api/v4/projects"

작업 토큰

job_token 매개변수나 JOB-TOKEN 헤더를 사용하여 특정 API 엔드포인트와 인증하기 위해 작업 토큰을 사용할 수 있습니다. GitLab CI/CD 작업에서 토큰을 전달하려면 CI_JOB_TOKEN 변수를 사용하세요.

매개변수에서 작업 토큰을 사용하는 예:

curl --location --output artifacts.zip "https://gitlab.example.com/api/v4/projects/1/jobs/42/artifacts?job_token=$CI_JOB_TOKEN"

헤더에서 작업 토큰을 사용하는 예:

curl --header "JOB-TOKEN:$CI_JOB_TOKEN" "https://gitlab.example.com/api/v4/projects/1/releases"

세션 쿠키

주요 GitLab 애플리케이션에 로그인하면 _gitlab_session 쿠키가 설정됩니다. API는 이 쿠키를 사용하여 인증을 수행합니다. 새로운 세션 쿠키를 생성하기 위해 API를 사용하는 것은 지원되지 않습니다.

이 인증 방법의 주요 사용자는 GitLab 자체의 웹 프론트엔드입니다. 웹 프론트엔드는 API를 사용하여 인증된 사용자로서 액세스 토큰을 명시적으로 전달하지 않고도 프로젝트 목록을 가져올 수 있습니다.

행세 토큰

행세 토큰은 개인 액세스 토큰의 한 종류입니다.
관리자만 생성할 수 있으며, 특정 사용자로 API와 인증하는 데 사용됩니다.

행세 토큰을 대안으로 사용하세요:

사용자의 비밀번호 또는 그들의 개인 액세스 토큰 중 하나.
Sudo 기능. 사용자의 비밀번호 또는 토큰 은 알 수 없거나 시간이 지남에 따라 변경될 수 있습니다.

자세한 내용은 사용자 토큰 API 문서를 참조하세요.

행세 토큰은 일반 개인 액세스 토큰처럼 사용되며, private_token 매개변수나 PRIVATE-TOKEN 헤더에 전달할 수 있습니다.

임직원 비활성화

기본적으로 임직원 기능이 활성화되어 있습니다. 임직원 기능을 비활성화하려면:

Linux 패키지 (Omnibus)

/etc/gitlab/gitlab.rb 파일을 편집합니다:

gitlab_rails['impersonation_enabled'] = false

파일을 저장한 후, 재구성하여 변경 사항이 적용되도록 합니다.

자체 컴파일 (소스)

config/gitlab.yml 파일을 편집합니다:
```
gitlab:
  impersonation_enabled: false
```
파일을 저장한 후, 재시작하여 변경 사항이 적용되도록 합니다.

임직원 기능을 다시 활성화하려면 이 구성을 제거하고 GitLab을 재구성(리눅스 패키지 설치)하거나 GitLab을 재시작(자체 컴파일 설치)합니다.

Sudo

모든 API 요청은 관리자로 인증된 경우 다른 사용자의 API 요청을 수행할 수 있습니다. 이때 OAuth 또는 sudo 범위가 있는 개인 액세스 토큰이 필요합니다. API 요청은 임직원 사용자의 권한으로 실행됩니다.

관리자로서 sudo 매개변수를 쿼리 문자열이나 수행할 작업을 원하는 사용자 ID 또는 사용자 이름(대소문자 구분 없음)을 포함한 헤더를 사용하여 전달합니다. 헤더로 전달할 경우 헤더 이름은 Sudo 여야 합니다.

비관리자의 액세스 토큰이 제공되면 GitLab은 403 상태 코드와 함께 오류 메시지를 반환합니다:

{
  "message": "403 Forbidden - Must be admin to use sudo"
}

sudo 범위가 없는 액세스 토큰이 제공되면 오류 메시지가 403 상태 코드와 함께 반환됩니다:

{
  "error": "insufficient_scope",
  "error_description": "The request requires higher privileges than provided by the access token.",
  "scope": "sudo"
}

sudo 사용자 ID 또는 사용자 이름을 찾을 수 없는 경우, 404 상태 코드와 함께 오류 메시지가 반환됩니다:

{
  "message": "404 User with ID or username '123' Not Found"
}

유효한 API 요청 및 cURL을 사용하여 sudo 요청을 제공하는 예 (사용자 이름 제공):

GET /projects?private_token=<your_access_token>&sudo=username

curl --header "PRIVATE-TOKEN: <your_access_token>" --header "Sudo: username" "https://gitlab.example.com/api/v4/projects"

유효한 API 요청 및 cURL을 사용하여 sudo 요청을 제공하는 예 (ID 제공):

GET /projects?private_token=<your_access_token>&sudo=23

curl --header "PRIVATE-TOKEN: <your_access_token>" --header "Sudo: 23" "https://gitlab.example.com/api/v4/projects"

요청 요구 사항

일부 REST API 요청은 데이터 형식 및 인코딩을 포함하여 특정 요구 사항이 있습니다.

요청 페이로드

API 요청은 쿼리 문자열 또는 페이로드 본문으로 전송된 매개변수를 사용할 수 있습니다. GET 요청은 일반적으로 쿼리 문자열을 전송하고, PUT 또는 POST 요청은 일반적으로 페이로드 본문을 전송합니다:

쿼리 문자열:

curl --request POST "https://gitlab/api/v4/projects?name=<example-name>&description=<example-description>"

요청 페이로드 (JSON):

curl --request POST --header "Content-Type: application/json" \
     --data '{"name":"<example-name>", "description":"<example-description>"}' "https://gitlab/api/v4/projects"

URL 인코딩된 쿼리 문자열은 길이 제한이 있습니다. 너무 큰 요청은 414 Request-URI Too Large 오류 메시지를 발생시킵니다. 이는 페이로드 본문을 사용하여 해결할 수 있습니다.

경로 매개변수

엔드포인트에 경로 매개변수가 있는 경우, 문서에서 앞에 콜론이 붙어 표시됩니다.

예를 들어:

DELETE /projects/:id/share/:group_id

` :id 경로 매개변수는 프로젝트 ID로 대체되어야 하며, :group_id는 그룹의 ID로 대체되어야 합니다. 콜론 :`은 포함되지 않아야 합니다.

ID가 5인 프로젝트와 그룹 ID가 17인 경우 결과적인 cURL 요청은 다음과 같습니다:

curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/share/17"

URL 인코딩이 필요한 경로 매개변수가 있는 경우, 따라오는 것이 필수입니다. 그렇지 않으면 API 엔드포인트와 일치하지 않으며 404로 응답합니다. API 앞에 (예: Apache) 무언가가 있는 경우, URL 인코딩된 경로 매개변수를 디코딩하지 않도록 확인하세요.

`id` 대 `iid`

일부 API 리소스에는 유사한 이름의 두 개 필드가 있습니다. 예를 들어, 이슈, 병합 요청, 및 프로젝트 마일스톤. 필드는 다음과 같습니다:

id: 모든 프로젝트에서 고유한 ID.
iid: 추가적인 내부 ID(웹 UI에 표시됨)로, 단일 프로젝트의 범위 내에서 고유합니다.

리소스에 iid 필드와 id 필드가 모두 있는 경우, 일반적으로 iid 필드를 사용하여 리소스를 가져옵니다.

예를 들어, id: 42인 프로젝트가 id: 46과 iid: 5인 이슈를 가지고 있다고 가정해보세요. 이 경우:

이슈를 검색하기 위한 유효한 API 요청은 GET /projects/42/issues/5입니다.
이슈를 검색하기 위한 유효하지 않은 API 요청은 GET /projects/42/issues/46입니다.

모든 iid 필드를 가진 리소스가 iid로 가져오는 것은 아닙니다. 어떤 필드를 사용할지에 대한 안내는 특정 리소스에 대한 문서를 참조하세요.

인코딩

REST API 요청을 할 때, 일부 콘텐츠는 특수 문자 및 데이터 구조를 고려하여 인코딩되어야 합니다.

네임스페이스 경로

네임스페이스 API 요청을 사용하는 경우, NAMESPACE/PROJECT_PATH가 URL 인코딩되어야 합니다.

예를 들어, /는 %2F로 표현됩니다:

GET /api/v4/projects/diaspora%2Fdiaspora

프로젝트의 _경로_는 반드시 _이름_과 동일하지 않습니다. 프로젝트의 경로는 프로젝트의 URL이나 프로젝트 설정의 일반 > 고급 > 경로 변경에서 찾을 수 있습니다.

파일 경로, 브랜치 및 태그 이름

파일 경로, 브랜치 또는 태그에 /가 포함되어 있을 경우, URL 인코딩되어야 합니다.

예를 들어, /는 %2F로 표현됩니다:

GET /api/v4/projects/1/repository/files/src%2FREADME.md?ref=master
GET /api/v4/projects/1/branches/my%2Fbranch/commits
GET /api/v4/projects/1/repository/tags/my%2Ftag

배열 및 해시 타입

array 및 hash 타입 매개변수로 API 요청을 할 수 있습니다:

`array`

import_sources는 array 타입의 매개변수입니다:

curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
-d "import_sources[]=github" \
-d "import_sources[]=bitbucket" \
"https://gitlab.example.com/api/v4/some_endpoint"

`hash`

override_params는 hash 타입의 매개변수입니다:

curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
--form "namespace=email" \
--form "path=impapi" \
--form "file=@/path/to/somefile.txt" \
--form "override_params[visibility]=private" \
--form "override_params[some_other_param]=some_value" \
"https://gitlab.example.com/api/v4/projects/import"

Array of hashes

variables는 해시 키/값 쌍을 포함하는 array 타입의 매개변수입니다
[{ 'key': 'UPLOAD_TO_S3', 'value': 'true' }]:

curl --globoff --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
"https://gitlab.example.com/api/v4/projects/169/pipeline?ref=master&variables[0][key]=VAR1&variables[0][value]=hello&variables[1][key]=VAR2&variables[1][value]=world"

curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
--header "Content-Type: application/json" \
--data '{ "ref": "master", "variables": [ {"key": "VAR1", "value": "hello"}, {"key": "VAR2", "value": "world"} ] }' \
"https://gitlab.example.com/api/v4/projects/169/pipeline"

Encoding `+` in ISO 8601 dates

쿼리 매개변수에 +를 포함해야 하는 경우, 대신 %2B를 사용해야 할 수 있습니다.
이는 +가 공백으로 해석되는 W3 권장 사항 때문입니다.
예를 들어, ISO 8601 날짜에서 특정 시간을 ISO 8601 형식으로 포함하고 싶다면 다음과 같을 수 있습니다:

2017-10-17T23:11:13.000+05:30

쿼리 매개변수에 대한 올바른 인코딩은 다음과 같습니다:

2017-10-17T23:11:13.000%2B05:30

Evaluating a response

일부 경우 API 응답이 예상과 다를 수 있습니다. 문제에는 null 값 및 리디렉션이 포함될 수 있습니다.
응답에서 숫자 상태 코드를 수신하면 상태 코드를 참조하십시오.

`null` vs `false`

API 응답에서 일부 부울 필드는 null 값을 가질 수 있습니다.
null 부울은 기본값이 없으며 true 또는 false도 아닙니다.
GitLab은 부울 필드에서 null 값을 false와 동일하게 처리합니다.

부울 인수에서는 null이 아닌 true 또는 false 값만 설정해야 합니다.

Redirects

GitLab 16.4에서 api_redirect_moved_projects라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.

GitLab 16.7에서 일반적으로 사용 가능합니다. 기능 플래그 api_redirect_moved_projects가 제거되었습니다.

경로 변경 후 REST API는
엔드포인트가 이동되었음을 알리는 메시지로 응답할 수 있습니다.
이 경우 Location 헤더에 지정된 엔드포인트를 사용하십시오.

다른 경로로 이동된 프로젝트의 예:

curl --verbose "https://gitlab.example.com/api/v4/projects/gitlab-org%2Fold-path-project"

응답은 다음과 같습니다:

...
< Location: http://gitlab.example.com/api/v4/projects/81
...
이 리소스는 https://gitlab.example.com/api/v4/projects/81로 영구적으로 이동되었습니다.

페이지 매김

GitLab은 다음의 페이지 매김 방법을 지원합니다:

오프셋 기반 페이지 매김. 기본 방식이며 users 엔드포인트를 제외한 모든 엔드포인트에서 사용할 수 있습니다. GitLab 16.5 이상에서는 users 엔드포인트에서 사용할 수 없습니다.
키셋 기반 페이지 매김. 선택된 엔드포인트에 추가되었으나 점진적으로 배포되고 있습니다.

대량의 컬렉션에서는 성능상의 이유로 오프셋 페이지 매김 대신 (사용 가능한 경우) 키셋 페이지 매김을 사용해야 합니다.

오프셋 기반 페이지 매김

users 엔드포인트는 GitLab 16.5에서 오프셋 기반 페이지 매김을 사용 중지(deprecated)로 전환하였으며 17.0에서 제거될 예정입니다. 이 변경 사항은 파괴적인 변경 사항입니다. 대신 이 엔드포인트에 대해 키셋 기반 페이지 매김을 사용하세요.

users 엔드포인트는 GitLab 17.0에서 요청된 레코드 수가 50,000보다 클 경우 키셋 기반 페이지 매김을 강제합니다.

때때로 반환된 결과가 여러 페이지에 걸쳐 있을 수 있습니다. 리소스를 나열할 때 다음 매개변수를 전달할 수 있습니다:

매개변수	설명
`page`	페이지 번호 (기본값: `1`).
`per_page`	페이지당 나열할 항목 수 (기본값: `20`, 최대: `100`).

다음 예제에서는 페이지당 50개의 네임스페이스를 나열합니다:

curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/namespaces?per_page=50"

주목: 오프셋 페이지 매김에 대한 허용 최대 오프셋 한도가 있습니다. 자체 관리 인스턴스에서 한도를 변경할 수 있습니다.

페이지 매김 `Link` 헤더

Link 헤더는 각 응답과 함께 반환됩니다. 이들은 rel이 prev, next, first 또는 last로 설정되어 있으며 관련 URL을 포함합니다. 자신의 URL을 생성하는 대신 이 링크를 사용해야 합니다.

GitLab.com 사용자에게는 일부 페이지 매김 헤더가 반환되지 않을 수 있습니다.

다음 cURL 예제에서는 페이지당 세 항목(per_page=3)으로 출력을 제한하고 ID가 9인 프로젝트에 속하는 이슈의 ID가 8인 댓글의 두 번째 페이지(page=2)를 요청합니다:

curl --head --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/9/issues/8/notes?per_page=3&page=2"

응답은 다음과 같습니다:

HTTP/2 200 OK
cache-control: no-cache
content-length: 1103
content-type: application/json
date: Mon, 18 Jan 2016 09:43:18 GMT
link: <https://gitlab.example.com/api/v4/projects/8/issues/8/notes?page=1&per_page=3>; rel="prev", <https://gitlab.example.com/api/v4/projects/8/issues/8/notes?page=3&per_page=3>; rel="next", <https://gitlab.example.com/api/v4/projects/8/issues/8/notes?page=1&per_page=3>; rel="first", <https://gitlab.example.com/api/v4/projects/8/issues/8/notes?page=3&per_page=3>; rel="last"
status: 200 OK
vary: Origin
x-next-page: 3
x-page: 2
x-per-page: 3
x-prev-page: 1
x-request-id: 732ad4ee-9870-4866-a199-a9db0cde3c86
x-runtime: 0.108688
x-total: 8
x-total-pages: 3

기타 페이지 매김 헤더

GitLab은 다음 추가 페이지 매김 헤더도 반환합니다:

헤더	설명
`x-next-page`	다음 페이지의 인덱스.
`x-page`	현재 페이지의 인덱스 (1부터 시작).
`x-per-page`	페이지당 항목 수.
`x-prev-page`	이전 페이지의 인덱스.
`x-total`	총 항목 수.
`x-total-pages`	총 페이지 수.

GitLab.com 사용자에게는 일부 페이지 매김 헤더가 반환되지 않을 수 있습니다.

키셋 기반 페이지 매김

키셋 페이지 매김은 페이지를 보다 효율적으로 검색할 수 있게 하며, 오프셋 기반 페이지 매김과 달리 실행 시간은 컬렉션의 크기에 영향을 받지 않습니다.

이 방법은 다음 파라미터에 의해 제어됩니다. order_by 및 sort는 모두 필수입니다.

파라미터	필수	설명
`pagination`	예	`keyset` (키셋 페이지 매김을 활성화).
`per_page`	아니오	페이지당 나열할 항목 수 (기본: `20`, 최대: `100`).
`order_by`	예	정렬할 열.
`sort`	예	정렬 순서 (`asc` 또는 `desc`).

다음 예제에서는 id 오름차순으로 정렬하여 페이지당 50 프로젝트를 나열합니다.

curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects?pagination=keyset&per_page=50&order_by=id&sort=asc"

응답 헤더에는 다음 페이지에 대한 링크가 포함되어 있습니다. 예를 들어:

HTTP/1.1 200 OK
...
Link: <https://gitlab.example.com/api/v4/projects?pagination=keyset&per_page=50&order_by=id&sort=asc&id_after=42>; rel="next"
Status: 200 OK
...

다음 페이지에 대한 링크에는 이미 검색된 레코드를 제외하는 추가 필터 id_after=42가 포함되어 있습니다.

또 다른 예로, 다음 요청은 키셋 페이지 매김을 사용하여 페이지당 name 오름차순으로 50 그룹을 나열합니다:

curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups?pagination=keyset&per_page=50&order_by=name&sort=asc"

응답 헤더에는 다음 페이지에 대한 링크가 포함되어 있습니다:

HTTP/1.1 200 OK
...
Link: <https://gitlab.example.com/api/v4/groups?pagination=keyset&per_page=50&order_by=name&sort=asc&cursor=eyJuYW1lIjoiRmxpZ2h0anMiLCJpZCI6IjI2IiwiX2tkIjoibiJ9>; rel="next"
Status: 200 OK
...

다음 페이지에 대한 링크에는 이미 검색된 레코드를 제외하는 추가 필터 cursor=eyJuYW1lIjoiRmxpZ2h0anMiLCJpZCI6IjI2IiwiX2tkIjoibiJ9가 포함되어 있습니다.

필터 유형은 사용된 order_by 옵션에 따라 다르며, 추가 필터를 여러 개 가질 수 있습니다.

경고:

Links 헤더는 W3C Link 사양에 맞추어 제거되었습니다. 대신 Link 헤더를 사용해야 합니다.

컬렉션의 끝에 도달하고 검색할 추가 레코드가 없을 경우, Link 헤더는 없으며 결과 배열은 비어 있습니다.

당신은 다음 페이지를 검색하기 위해 주어진 링크만 사용해야 하며, 자신의 URL을 구축해서는 안 됩니다. 표시된 헤더 외에는 추가 페이지 매김 헤더를 노출하지 않습니다.

지원되는 리소스

키셋 기반 페이지네이션은 선택된 리소스 및 정렬 옵션에 대해서만 지원됩니다:

리소스	옵션	가용성
그룹 감사 이벤트	`order_by=id`, `sort=desc`만	인증된 사용자만 사용 가능.
그룹	`order_by=name`, `sort=asc`만	인증되지 않은 사용자만 사용 가능.
인스턴스 감사 이벤트	`order_by=id`, `sort=desc`만	인증된 사용자만 사용 가능.
패키지 파이프라인	`order_by=id`, `sort=desc`만	인증된 사용자만 사용 가능.
프로젝트 작업	`order_by=id`, `sort=desc`만	인증된 사용자만 사용 가능.
프로젝트 감사 이벤트	`order_by=id`, `sort=desc`만	인증된 사용자만 사용 가능.
프로젝트들	`order_by=id`만	인증된 사용자 및 인증되지 않은 사용자 모두 사용 가능.
사용자들	`order_by=id`, `order_by=name`, `order_by=username`	인증된 사용자 및 인증되지 않은 사용자 모두 사용 가능. GitLab 16.5에 도입됨.
레지스트리 리포지토리 태그	`order_by=name`, `sort=asc`, 또는 `sort=desc`만	인증된 사용자만 사용 가능.
리포지토리 트리 목록	해당 없음	인증된 사용자 및 인증되지 않은 사용자 모두 사용 가능. GitLab 17.1에 도입됨.

페이지네이션 응답 헤더

성능상의 이유로, 쿼리가 10,000개 이상의 레코드를 반환하면 GitLab은 다음 헤더를 반환하지 않습니다:

x-total.
x-total-pages.
rel="last" link

REST API

REST API 요청 만들기

비율 제한

응답 형식

인증

OAuth 2.0 토큰

개인/프로젝트/그룹 액세스 토큰

작업 토큰

세션 쿠키

행세 토큰

임직원 비활성화

Sudo

요청 요구 사항

요청 페이로드

경로 매개변수

`id` 대 `iid`

인코딩

네임스페이스 경로

파일 경로, 브랜치 및 태그 이름

배열 및 해시 타입

`array`

`hash`

Array of hashes

Encoding `+` in ISO 8601 dates

Evaluating a response

`null` vs `false`

Redirects

페이지 매김

오프셋 기반 페이지 매김

페이지 매김 `Link` 헤더

기타 페이지 매김 헤더

키셋 기반 페이지 매김

지원되는 리소스

페이지네이션 응답 헤더

도움말

기능 사용 가능성과 제품 평가판

도움받기

REST API

REST API 요청 만들기

비율 제한

응답 형식

인증

OAuth 2.0 토큰

개인/프로젝트/그룹 액세스 토큰

작업 토큰

세션 쿠키

행세 토큰

임직원 비활성화

Sudo

요청 요구 사항

요청 페이로드

경로 매개변수

id 대 iid

인코딩

네임스페이스 경로

파일 경로, 브랜치 및 태그 이름

배열 및 해시 타입

array

hash

Array of hashes

Encoding + in ISO 8601 dates

Evaluating a response

null vs false

Redirects

페이지 매김

오프셋 기반 페이지 매김

페이지 매김 Link 헤더

기타 페이지 매김 헤더

키셋 기반 페이지 매김

지원되는 리소스

페이지네이션 응답 헤더

도움말

기능 사용 가능성과 제품 평가판

도움받기

`id` 대 `iid`

`array`

`hash`

Encoding `+` in ISO 8601 dates

`null` vs `false`

페이지 매김 `Link` 헤더