REST API

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

GitLab REST API를 사용하여 호환되는 모든 REST API 클라이언트를 통해 데이터를 검색합니다.

REST API 버전은 의미 있는 버전 지정 명세를 준수합니다. 주 버전 숫자는 4입니다. 하위 호환성이 없는 변경 사항은 이 버전 번호가 변경되어야 합니다.

마이너 버전은 명시적이지 않아 안정적인 API 엔드포인트를 가능하게 합니다.
새로운 기능은 동일한 버전 번호에서 API에 추가됩니다.
주요 API 버전 변경 및 전체 API 버전 제거는 주요 GitLab 릴리스와 함께 실행됩니다.
모든 폐지 사항 및 버전 간 변경 사항은 문서에 기록됩니다.

REST API 리소스에서 표시된 항목 외에는 각 시간에 알림 없이 제거될 수 있으며 다음과 같습니다:

REST API resources에 ‘실험 또는 베타’로 표시된 요소들.
기능 플래그 뒤에 있는 필드들은 기본적으로 비활성화됩니다.

REST API 요청 생성

REST API 요청을 생성하려면:

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

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

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

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

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

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

요율 제한

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

자세한 정보는 Rate limits를 참조하십시오.
GitLab.com에서 사용하는 요율 제한 설정의 자세한 정보는 GitLab.com-specific rate limits를 참조하십시오.

응답 형식

REST API 응답은 JSON 형식으로 반환됩니다. 일부 API 엔드포인트는 일반 텍스트 형식도 지원합니다. 엔드포인트가 지원하는 콘텐츠 유형을 확인하려면 REST API resources를 참조하십시오.

인증

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

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

OAuth 2.0 tokens
Personal access tokens
Project access tokens
Group access tokens
Session cookie
GitLab CI/CD job token (특정 엔드포인트만 해당)

프로젝트 액세스 토큰은 다음과 같이 지원됩니다:

Self-managed GitLab: Free, Premium, 그리고 Ultimate.
GitLab SaaS: Premium 그리고 Ultimate.

관리자인 경우, 애플리케이션 또는 사용자로 특정 사용자로 인증할 수 있습니다.

임의 인증 tokens
Sudo

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

{
  "message": "401 Unauthorized"
}

참고: 배포 토큰은 GitLab 공개 API에서 사용할 수 없습니다. 자세한 내용은 Deploy Tokens를 참조하십시오.

OAuth 2.0 토큰

OAuth 2.0 token을 사용하여 access_token 매개변수 또는 Authorization 헤더를 통해 API와 인증할 수 있습니다.

매개변수로 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"

GitLab OAuth 2.0 제공자로서의 GitLab에 대해 자세히 알아보십시오.

참고: 모든 OAuth 액세스 토큰은 생성된 후 2시간 동안 유효합니다. refresh_token 매개변수를 사용하여 토큰을 새로 고칠 수 있습니다. 새로운 액세스 토큰을 요청하는 방법에 대한 자세한 내용은 OAuth 2.0 token 문서를 참조하십시오.

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

액세스 토큰을 사용하여 private_token 매개변수 또는 PRIVATE-TOKEN 헤더를 통해 API와 인증할 수 있습니다.

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

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"

작업 토큰

특정 API 엔드포인트에 대해 작업 토큰을 사용하여 토큰을 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

파일을 저장한 후 변경 사항이 적용되도록 GitLab을 다시 구성합니다.

직접 설치한 경우 (소스)

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

타인 사용을 다시 활성화하려면 이 구성을 제거하고 GitLab을 다시 구성(Linux 패키지 설치)하거나 GitLab을 다시 시작합니다(자체 컴파일 설치).

Sudo

모든 API 요청은 sudo 스코프가 있는 OAuth 또는 개인 액세스 토큰으로 관리자로서 인증될 경우 다른 사용자처럼 API 요청을 수행하는 것을 지원합니다. API 요청은 대리된 사용자의 권한으로 실행됩니다.

관리자로서 수행하려면 사용자의 ID 또는 사용자 이름(대소문자 구분 없음)의 쿼리 문자열 또는 헤더로 sudo 매개변수를 전달하세요. 헤더로 전달하는 경우 헤더 이름은 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"
}

대리자 사용자 ID 또는 사용자 이름을 찾을 수 없는 경우 상태 코드가 404인 오류 메시지가 반환됩니다:

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

유효한 API 요청 및 sudo 요청을 사용하는 cURL 요청 예제로서 사용자 이름을 제공합니다:

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 요청 및 sudo 요청을 사용하는 cURL 요청 예제로서 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로 응답합니다. (예: Apache와 같은 것 앞에 무언가 있는 경우 URL 인코딩된 경로 매개변수를 디코딩하지 않는지 확인해야 합니다.)

`id` vs `iid`

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

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

리소스에 iid 필드와 id 필드가 모두 있는 경우 보통 리소스를 가져오기 위해 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이나 프로젝트 설정에서 General > Advanced > Change path에 있습니다.

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

파일 경로, 브랜치 또는 태그에 /가 포함되어 있는 경우 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"

해시의 배열

variables는 키/값 쌍을 포함하는 hash 유형의 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"

ISO 8601 날짜에서 `+`의 인코딩

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

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

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

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

응답 평가

일부 상황에서 API 응답이 예상대로 되지 않을 수 있습니다. 이슈에는 널 값 및 리디렉션이 포함될 수 있습니다. 응답에서 숫자 상태 코드를 받은 경우 상태 코드를 참조하십시오.

`null` vs `false`

API 응답에서 일부 boolean 필드에는 null 값이 포함될 수 있습니다. null boolean에는 기본값이 없으며 true나 false도 아닙니다. GitLab은 boolean 필드의 null 값을 false와 동일하게 취급합니다.

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

리디렉트

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
...
This resource has been moved permanently to https://gitlab.example.com/api/v4/projects/81

페이지네이션

GitLab은 다음과 같은 페이지네이션 방법을 지원합니다:

오프셋 기반 페이지네이션. 기본 방식으로 모든 엔드포인트에서 사용 가능하며 GitLab 16.5 이후 users 엔드포인트에서는 사용할 수 없습니다.
키셋 기반 페이지네이션. 선택한 엔드포인트에 추가되었으며 점진적으로 롤아웃 중입니다.

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

오프셋 기반 페이지네이션

GitLab 16.5에서 오프셋 기반 페이지네이션을 위한 users 엔드포인트가 중지 예정되었으며 17.0에서 제거 예정입니다. 이 변경은 호환성을 파괴하는 변경입니다. 이 엔드포인트에 대해 대신 키셋 기반 페이지네이션을 사용하십시오.
GitLab 17.0에서 users 엔드포인트는 5만 건 이상의 레코드를 요청할 경우 키셋 기반 페이지네이션을 강제합니다.

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

매개변수	설명
`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"

참고: 오프셋 페이지네이션의 최대 허용 제한이 있습니다. Self-Managed 인스턴스에서 제한을 변경할 수 있습니다.

Pagination `Link` 헤더

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

GitLab.com 사용자의 경우, 일부 페이징 헤더가 반환되지 않을 수 있습니다.

다음 cURL 예제에서는 페이지당 아이템을 3개로 제한하고(per_page=3), 이슈 ID가 8이고 프로젝트 ID가 9인 이슈의 코멘트 중 두 번째 페이지(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`).

다음 예제에서는 페이지당 50개의 프로젝트를 ID를 기준으로 오름차순으로 나열합니다.

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가 포함되어 있습니다.

또 다른 예로, 다음 요청은 이름을 기준으로 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 옵션에 따라 다르며, 추가 필터가 하나 이상 있을 수 있습니다.

경고: W3C Link specification에 맞추기 위해 Links 헤더는 제거되었습니다. 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" 링크

REST API

REST API 요청 생성

요율 제한

응답 형식

인증

OAuth 2.0 토큰

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

작업 토큰

세션 쿠키

타인 토큰

타인 사용 비활성화

Sudo

요청 요구 사항

요청 페이로드

경로 매개변수

`id` vs `iid`

인코딩

네임스페이스 경로

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

배열 및 해시 유형

`array`

`hash`

해시의 배열

ISO 8601 날짜에서 `+`의 인코딩

응답 평가

`null` vs `false`

리디렉트

페이지네이션

오프셋 기반 페이지네이션

기타 페이징 헤더

키셋 기반 페이징

지원되는 리소스

페이지네이션 응답 헤더

도움말

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

도움받기

REST API

REST API 요청 생성

요율 제한

응답 형식

인증

OAuth 2.0 토큰

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

작업 토큰

세션 쿠키

타인 토큰

타인 사용 비활성화

Sudo

요청 요구 사항

요청 페이로드

경로 매개변수

id vs iid

인코딩

네임스페이스 경로

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

배열 및 해시 유형

array

hash

해시의 배열

ISO 8601 날짜에서 +의 인코딩

응답 평가

null vs false

리디렉트

페이지네이션

오프셋 기반 페이지네이션

Pagination Link 헤더

기타 페이징 헤더

키셋 기반 페이징

지원되는 리소스

페이지네이션 응답 헤더

도움말

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

도움받기

`id` vs `iid`

`array`

`hash`

ISO 8601 날짜에서 `+`의 인코딩

`null` vs `false`

Pagination `Link` 헤더