A list of methods and URIs are covered in the table below:
| Method |
Path |
Entity |
Description |
| GET |
/v2/ |
Base |
Check that the endpoint implements Docker Registry API V2. |
| GET |
/v2/<name>/tags/list |
Tags |
Fetch the tags under the repository identified by name. |
| GET |
/v2/<name>/manifests/<reference> |
Manifest |
Fetch the manifest identified by name and reference where reference can be a tag or digest. A HEAD request can also be issued to this endpoint to obtain resource information without receiving all data. |
| PUT |
/v2/<name>/manifests/<reference> |
Manifest |
Put the manifest identified by name and reference where reference can be a tag or digest. |
| DELETE |
/v2/<name>/manifests/<reference> |
Manifest |
Delete the manifest identified by name and reference. Note that a manifest can only be deleted by digest. |
| GET |
/v2/<name>/blobs/<digest> |
Blob |
Retrieve the blob from the registry identified by digest. A HEAD request can also be issued to this endpoint to obtain resource information without receiving all data. |
| DELETE |
/v2/<name>/blobs/<digest> |
Blob |
Delete the blob identified by name and digest |
| POST |
/v2/<name>/blobs/uploads/ |
Initiate Blob Upload |
Initiate a resumable blob upload. If successful, an upload location will be provided to complete the upload. Optionally, if the digest parameter is present, the request body will be used to complete the upload in a single request. |
| GET |
/v2/<name>/blobs/uploads/<uuid> |
Blob Upload |
Retrieve status of upload identified by uuid. The primary purpose of this endpoint is to resolve the current status of a resumable upload. |
| 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. |
Paginated catalog results can be retrieved by adding an n parameter to the request URL, declaring that the response should be limited to n results. Starting a paginated flow begins 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
Link: <<url>?n=<n from the request>&last=<last repository in response>>; rel="next"
{
"repositories": [
<name>,
...
]
}
The above includes the first n entries from the result set. To get the next n entries, one can create a URL where the argument last has the value from repositories[len(repositories)-1]. If there are indeed more results, the URL for the next block is encoded in an RFC5988 Link header, as a “next” relation. The presence of the Link header communicates to the client that the entire result set has not been returned and another request must be issued. If the header is not present, the client can assume that all results have been received.
NOTE: In the request template above, note that the brackets are required. For example, if the url ishttp://example.com/v2/_catalog?n=20&last=b, the value of the header would be <http://example.com/v2/_catalog?n=20&last=b>; rel="next". Please see RFC5988 for details.
Compliant client implementations should always use the Link header value when proceeding through results linearly. The client may construct URLs to skip forward in the catalog.
To get the next result set, a client would issue the request as follows, using the URL encoded in the described Link header:
GET /v2/_catalog?n=<n from the request>&last=<last repository value from previous response>
The above process should then be repeated until the Link header is no longer set.
The catalog result set 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 us say the registry has the following repositories:
If the value of n is 2, a and b will be returned on the first response. The Link header returned on the response will have n set to 2 and last set to b:
Link: <<url>?n=2&last=b>; rel="next"
The client can then issue the request with the above value from the Link header, receiving the values c and d. Note that n may change on the second to last response or be fully omitted, depending on the server implementation.