alexvanin/distribution
1
0
Fork 0
forked from TrueCloudLab/distribution
Code Pull requests Activity

Catalog V2 API specification proposal

Browse source 
This contains a proposal for a catalog API, provided access to the internal
contents of a registry instance. The API endpoint is prefixed with an
underscore, which is illegal in images names, to prevent collisions with
repositories names. To avoid issues with large result sets, a paginated version
of the API is proposed. We make an addition to the tags API to support
pagination to ensure the specification is conistent.

Signed-off-by: Stephen J Day <stephen.day@docker.com>
This commit is contained in:
Stephen J Day 2015-06-01 19:10:51 -07:00 committed by Patrick Devine
parent c152ad7d2d
commit aebe850f73
4 changed files with 640 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

331
docs/spec/api.md
View file

@ -120,6 +120,16 @@ indicating what is different. Optionally, we may start marking parts of the
specification to correspond with the versions enumerated here.
<dl>
<dt>2.0.4</dt>>
<dd>
<ul>
<li>Added support for listing registry contents.</li>
<li>Added pagination to tags API.</li>
<li>Added common approach to support pagination.</li>
</ul>
</dd>
<dt>2.0.3</dt>
<dd>
<li>Allow repository name components to be one character.</li>
@ -131,7 +141,6 @@ specification to correspond with the versions enumerated here.
<li>Added section covering digest format.</li>
<li>Added more clarification that manifest cannot be deleted by tag.</li>
</dd>
<dt>2.0.1</dt>
<dd>
<ul>
@ -745,7 +754,9 @@ each unknown blob. The response format is as follows:
]
}
#### Listing Image Tags
### Listing Image Tags
It may be necessary to list all of the tags under a given repository. The tags
for an image repository can be retrieved with the following request:
@ -766,8 +777,166 @@ The response will be in the following format:
}
For repositories with a large number of tags, this response may be quite
large, so care should be taken by the client when parsing the response to
reduce copying.
large. If such a response is expected, one should use the pagination.
#### Pagination
Paginated tag results can be retrieved by adding the appropriate pagination
parameters. Starting a paginated flow may begin as follows:
```
GET /v2/<name>/tags/list?n=<integer>
```
The above specifies that a tags response should be returned, from the start of
the result set, ordered lexically, limiting the number of results to `n`. The
response to such a request would look as follows:
```
200 OK
Content-Type: application/json
{
"name": <name>,
"tags": [
<tag>,
...
]
"next": <url>?n=<n from the request>&last=<last tag value from previous response>
}
```
> __TODO(stevvooe):__ Consider using a Header here, rather than a body parameter. A
header would allow one to issue the next request before parsing the response
body.
To get the next result set, a client would issue the request as follows, using
the value of "next" from the response body:
```
GET /v2/<name>/tags/list?n=<n from the request>&last=<last tag value from previous response>
```
The above process should then be repeated until the `next` parameter is no
longer set in the response.
The behavior of `last` is quite simple and can be demonstrated with an
example. Let's say the repository has the following tags:
```
a
b
c
d
```
If the value of `n` is 2, _a_ and _b_ will be returned on the first response.
The `next` url within the respone will have `n` set to 2 and last set to _b_:
```
"next": <url>?n=2&last=b
```
The client can then issue the response, receiving the values _c_ and _d_. Note
that n may change on second to last response or be omitted fully, if the
server may so choose.
### Listing Repositories
Images are stored in collections, known as a _repository_, which is keyed by a
`name`, as seen throughout the API specification. A registry instance may
contain several repositories. The list of available repositories, or image
names, is made available through the _catalog_.
The catalog for a given registry can be retrived with the following request:
```
GET /v2/_catalog
```
The response will be in the following format:
```
200 OK
Content-Type: application/json
{
"repositories": [
<name>,
...
]
}
```
For registries with a large number of repositories, this response may be quite
large. If such a response is expected, one should use the pagination.
#### Pagination
Paginated repository results can be retrieved by adding the appropriate
pagination parameters, which are similar to those available in the tag API.
Starting a paginated flow may begin as follows:
```
GET /v2/_catalog?n=<integer>
```
The above specifies that a catalog response should be returned, from the start of
the result set, ordered lexically, limiting the number of results to `n`. The
response to such a request would look as follows:
```
200 OK
Content-Type: application/json
{
"repositories": [
<name>,
...
]
"next": <url>?n=<n from the request>&last=<last repository value from previous response>
}
```
> __TODO(stevvooe):__ Consider using a Header here, rather than a body parameter. A
header would allow one to issue the next request before parsing the response
body.
To get the next result set, a client would issue the request as follows, using
the value of "next" from the response body:
```
GET /v2/_catalog?n=<n from the request>&last=<last repostory value from previous response>
```
The above process should then be repeated until the `next` parameter is no
longer set in the response.
The result set of repository names is represented abstractly as a lexically
sorted list, where the position in that list can be specified by the query
term `last`. The entries in the response start _after_ the term specified by
`last`, up to `n` entries.
The behavior of `last` is quite simple when demonstrated with an example.
Let's say the registry has the following repositories:
```
a
b
c
d
```
If the value of `n` is 2, _a_ and _b_ will be returned on the first response.
The `next` url within the respone will have `n` set to 2 and last set to _b_:
```
"next": <url>?n=2&last=b
```
The client can then issue the request with above value of `next`, receiving
the values _c_ and _d_. Note that n may change on second to last response or
be omitted fully, if the server may so choose.
### Deleting an Image
@ -817,6 +986,7 @@ A list of methods and URIs are covered in the table below:
| PATCH | `/v2/<name>/blobs/uploads/<uuid>` | Blob Upload | Upload a chunk of data for the specified upload. |
| PUT | `/v2/<name>/blobs/uploads/<uuid>` | Blob Upload | Complete the upload specified by `uuid`, optionally appending the body as the final chunk. |
| DELETE | `/v2/<name>/blobs/uploads/<uuid>` | Blob Upload | Cancel outstanding upload processes, releasing associated resources. If this is not called, the unfinished uploads will eventually timeout. |
| GET | `/v2/_catalog` | Catalog | Retrieve a sorted, json list of repositories available in the registry. |
The detail for each endpoint is covered in the following sections.
@ -886,7 +1056,6 @@ The API implements V2 protocol and is accessible.
###### On Failure: Unauthorized
```
@ -1056,6 +1225,57 @@ The error codes that may be included in the response body are enumerated below:
```
GET /v2/<name>/tags/list?n=<integer>last=<integer>
```
Return a portion of the tags for the specified repository.
The following parameters should be specified on the request:
|Name|Kind|Description|
|----|----|-----------|
|`name`|path|Name of the target repository.|
|`n`|query|Limit the number of entries in each response. It not present, all entries will be returned.|
|`last`|query|Result set will include values lexically after last.|
###### On Success: OK
```
200 OK
Content-Length: <length>
Content-Type: application/json; charset=utf-8
{
"name": <name>,
"tags": [
<tag>,
...
],
"next": "<url>?last=<name>&n=<last value of n>"
}
```
A list of tags for the named repository.
The following fields may be returned in the response body:
|Name|Description|
|----|-----------|
|`next`|Provides the URL to get the next set of results, if available.|
The following headers will be returned with the response:
|Name|Description|
|----|-----------|
|`Content-Length`|Length of the JSON response body.|
### Manifest
@ -1453,7 +1673,6 @@ The following parameters should be specified on the request:
###### On Failure: Invalid Name or Reference
```
@ -2907,3 +3126,103 @@ The error codes that may be included in the response body are enumerated below:
### Catalog
List a set of available repositories in the local registry cluster. Does not provide any indication of what may be available upstream. Applications can only determine if a repository is available but not if it is not available.
#### GET Catalog
Retrieve a sorted, json list of repositories available in the registry.
##### Catalog Fetch Complete
```
GET /v2/_catalog
```
Request an unabridged list of repositories available.
###### On Success: OK
```
200 OK
Content-Length: <length>
Content-Type: application/json; charset=utf-8
{
"repositories": [
<name>,
...
]
}
```
Returns the unabridged list of repositories as a json response.
The following headers will be returned with the response:
|Name|Description|
|----|-----------|
|`Content-Length`|Length of the JSON response body.|
##### Catalog Fetch Paginated
```
GET /v2/_catalog?n=<integer>last=<integer>
```
Return the specified portion of repositories.
The following parameters should be specified on the request:
|Name|Kind|Description|
|----|----|-----------|
|`n`|query|Limit the number of entries in each response. It not present, all entries will be returned.|
|`last`|query|Result set will include values lexically after last.|
###### On Success: OK
```
200 OK
Content-Length: <length>
Content-Type: application/json; charset=utf-8
{
"repositories": [
<name>,
...
]
"next": "<url>?last=<name>&n=<last value of n>"
}
```
The following fields may be returned in the response body:
|Name|Description|
|----|-----------|
|`next`|Provides the URL to get the next set of results, if available.|
The following headers will be returned with the response:
|Name|Description|
|----|-----------|
|`Content-Length`|Length of the JSON response body.|

184
docs/spec/api.md.tmpl
View file

@ -120,6 +120,16 @@ indicating what is different. Optionally, we may start marking parts of the
specification to correspond with the versions enumerated here.
<dl>
<dt>2.0.4</dt>>
<dd>
<ul>
<li>Added support for listing registry contents.</li>
<li>Added pagination to tags API.</li>
<li>Added common approach to support pagination.</li>
</ul>
</dd>
<dt>2.0.3</dt>
<dd>
<li>Allow repository name components to be one character.</li>
@ -131,7 +141,6 @@ specification to correspond with the versions enumerated here.
<li>Added section covering digest format.</li>
<li>Added more clarification that manifest cannot be deleted by tag.</li>
</dd>
<dt>2.0.1</dt>
<dd>
<ul>
@ -745,7 +754,9 @@ each unknown blob. The response format is as follows:
]
}
#### Listing Image Tags
### Listing Image Tags
It may be necessary to list all of the tags under a given repository. The tags
for an image repository can be retrieved with the following request:
@ -766,8 +777,166 @@ The response will be in the following format:
}
For repositories with a large number of tags, this response may be quite
large, so care should be taken by the client when parsing the response to
reduce copying.
large. If such a response is expected, one should use the pagination.
#### Pagination
Paginated tag results can be retrieved by adding the appropriate pagination
parameters. Starting a paginated flow may begin as follows:
```
GET /v2/<name>/tags/list?n=<integer>
```
The above specifies that a tags response should be returned, from the start of
the result set, ordered lexically, limiting the number of results to `n`. The
response to such a request would look as follows:
```
200 OK
Content-Type: application/json
{
"name": <name>,
"tags": [
<tag>,
...
]
"next": <url>?n=<n from the request>&last=<last tag value from previous response>
}
```
> __TODO(stevvooe):__ Consider using a Header here, rather than a body parameter. A
header would allow one to issue the next request before parsing the response
body.
To get the next result set, a client would issue the request as follows, using
the value of "next" from the response body:
```
GET /v2/<name>/tags/list?n=<n from the request>&last=<last tag value from previous response>
```
The above process should then be repeated until the `next` parameter is no
longer set in the response.
The behavior of `last` is quite simple and can be demonstrated with an
example. Let's say the repository has the following tags:
```
a
b
c
d
```
If the value of `n` is 2, _a_ and _b_ will be returned on the first response.
The `next` url within the respone will have `n` set to 2 and last set to _b_:
```
"next": <url>?n=2&last=b
```
The client can then issue the response, receiving the values _c_ and _d_. Note
that n may change on second to last response or be omitted fully, if the
server may so choose.
### Listing Repositories
Images are stored in collections, known as a _repository_, which is keyed by a
`name`, as seen throughout the API specification. A registry instance may
contain several repositories. The list of available repositories, or image
names, is made available through the _catalog_.
The catalog for a given registry can be retrived with the following request:
```
GET /v2/_catalog
```
The response will be in the following format:
```
200 OK
Content-Type: application/json
{
"repositories": [
<name>,
...
]
}
```
For registries with a large number of repositories, this response may be quite
large. If such a response is expected, one should use the pagination.
#### Pagination
Paginated repository results can be retrieved by adding the appropriate
pagination parameters, which are similar to those available in the tag API.
Starting a paginated flow may begin as follows:
```
GET /v2/_catalog?n=<integer>
```
The above specifies that a catalog response should be returned, from the start of
the result set, ordered lexically, limiting the number of results to `n`. The
response to such a request would look as follows:
```
200 OK
Content-Type: application/json
{
"repositories": [
<name>,
...
]
"next": <url>?n=<n from the request>&last=<last repository value from previous response>
}
```
> __TODO(stevvooe):__ Consider using a Header here, rather than a body parameter. A
header would allow one to issue the next request before parsing the response
body.
To get the next result set, a client would issue the request as follows, using
the value of "next" from the response body:
```
GET /v2/_catalog?n=<n from the request>&last=<last repostory value from previous response>
```
The above process should then be repeated until the `next` parameter is no
longer set in the response.
The result set of repository names is represented abstractly as a lexically
sorted list, where the position in that list can be specified by the query
term `last`. The entries in the response start _after_ the term specified by
`last`, up to `n` entries.
The behavior of `last` is quite simple when demonstrated with an example.
Let's say the registry has the following repositories:
```
a
b
c
d
```
If the value of `n` is 2, _a_ and _b_ will be returned on the first response.
The `next` url within the respone will have `n` set to 2 and last set to _b_:
```
"next": <url>?n=2&last=b
```
The client can then issue the request with above value of `next`, receiving
the values _c_ and _d_. Note that n may change on second to last response or
be omitted fully, if the server may so choose.
### Deleting an Image
@ -867,8 +1036,13 @@ Content-Type: {{.Body.ContentType}}{{end}}{{if .Body.Format}}
```
{{.Description}}
{{if .Fields}}The following fields may be returned in the response body:
{{if .Headers}}The following headers will be returned with the response:
|Name|Description|
|----|-----------|
{{range .Fields}}|`{{.Name}}`|{{.Description}}|
{{end}}{{end}}{{if .Headers}}
The following headers will be returned with the response:
|Name|Description|
|----|-----------|

135
registry/api/v2/descriptors.go
View file

@ -87,6 +87,23 @@ var (
Format: "<digest>",
}
paginationParameters = []ParameterDescriptor{
{
Name: "n",
Type: "integer",
Description: "Limit the number of entries in each response. It not present, all entries will be returned.",
Format: "<integer>",
Required: false,
},
{
Name: "last",
Type: "string",
Description: "Result set will include values lexically after last.",
Format: "<integer>",
Required: false,
},
}
unauthorizedResponse = ResponseDescriptor{
Description: "The client does not have access to the repository.",
StatusCode: http.StatusUnauthorized,
@ -269,6 +286,9 @@ type ResponseDescriptor struct {
// Headers covers any headers that may be returned from the response.
Headers []ParameterDescriptor
// Fields describes any fields that may be present in the response.
Fields []ParameterDescriptor
// ErrorCodes enumerates the error codes that may be returned along with
// the response.
ErrorCodes []errcode.ErrorCode
@ -427,6 +447,44 @@ var routeDescriptors = []RouteDescriptor{
},
},
},
{
Description: "Return a portion of the tags for the specified repository.",
PathParameters: []ParameterDescriptor{nameParameterDescriptor},
QueryParameters: paginationParameters,
Successes: []ResponseDescriptor{
{
StatusCode: http.StatusOK,
Description: "A list of tags for the named repository.",
Headers: []ParameterDescriptor{
{
Name: "Content-Length",
Type: "integer",
Description: "Length of the JSON response body.",
Format: "<length>",
},
},
Fields: []ParameterDescriptor{
{
Name: "next",
Type: "url",
Description: "Provides the URL to get the next set of results, if available.",
Format: "<url>",
},
},
Body: BodyDescriptor{
ContentType: "application/json; charset=utf-8",
Format: `{
"name": <name>,
"tags": [
<tag>,
...
],
"next": "<url>?last=<name>&n=<last value of n>"
}`,
},
},
},
},
},
},
},
@ -1320,6 +1378,83 @@ var routeDescriptors = []RouteDescriptor{
},
},
},
{
Name: RouteNameCatalog,
Path: "/v2/_catalog",
Entity: "Catalog",
Description: "List a set of available repositories in the local registry cluster. Does not provide any indication of what may be available upstream. Applications can only determine if a repository is available but not if it is not available.",
Methods: []MethodDescriptor{
{
Method: "GET",
Description: "Retrieve a sorted, json list of repositories available in the registry.",
Requests: []RequestDescriptor{
{
Name: "Catalog Fetch Complete",
Description: "Request an unabridged list of repositories available.",
Successes: []ResponseDescriptor{
{
Description: "Returns the unabridged list of repositories as a json response.",
StatusCode: http.StatusOK,
Headers: []ParameterDescriptor{
{
Name: "Content-Length",
Type: "integer",
Description: "Length of the JSON response body.",
Format: "<length>",
},
},
Body: BodyDescriptor{
ContentType: "application/json; charset=utf-8",
Format: `{
"repositories": [
<name>,
...
]
}`,
},
},
},
},
{
Name: "Catalog Fetch Paginated",
Description: "Return the specified portion of repositories.",
QueryParameters: paginationParameters,
Successes: []ResponseDescriptor{
{
StatusCode: http.StatusOK,
Body: BodyDescriptor{
ContentType: "application/json; charset=utf-8",
Format: `{
"repositories": [
<name>,
...
]
"next": "<url>?last=<name>&n=<last value of n>"
}`,
},
Headers: []ParameterDescriptor{
{
Name: "Content-Length",
Type: "integer",
Description: "Length of the JSON response body.",
Format: "<length>",
},
},
Fields: []ParameterDescriptor{
{
Name: "next",
Type: "url",
Description: "Provides the URL to get the next set of results, if available.",
Format: "<url>",
},
},
},
},
},
},
},
},
},
}
var routeDescriptorsMap map[string]RouteDescriptor

1
registry/api/v2/routes.go
View file

@ -11,6 +11,7 @@ const (
RouteNameBlob = "blob"
RouteNameBlobUpload = "blob-upload"
RouteNameBlobUploadChunk = "blob-upload-chunk"
RouteNameCatalog = "catalog"
)
var allEndpoints = []string{