Manifests are now fetched by a field called "reference", which may be a tag or
a digest. When using digests to reference a manifest, the data is immutable.
The routes and specification have been updated to allow this.
There are a few caveats to this approach:
1. It may be problematic to rely on data format to differentiate between a tag
and a digest. Currently, they are disjoint but there may modifications on
either side that break this guarantee.
2. The caching characteristics of returned content are very different for
digest versus tag-based references. Digest urls can be cached forever while tag
urls cannot.
Both of these are minimal caveats that we can live with in the future.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
This changeset adds support for a header to identify docker upload uuids. This
id can be used as a key to manage local state for resumable uploads. The goal
is remove the necessity for a client to parse the url to get an upload uuid.
The restrictions for clients to use the location header are still strongly in
place.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Outlines the format of the tokens and how they are verified.
Outlines how clients should respond to bearer token authorization
challenges.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
The goal is to maintain a specification heirarchy under doc/spec. This change
sets the example. The Makefile has also been changed update the AUTHORS file
and can now generate the specification.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Many details have been updated in route descriptors. This commit regenerates
the specification from the latest changes and template.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
This changeset provides data structures and definitions describing the routes
available in the V2 registry API. These route descriptors are structured to
provide automated registration, for creating routers, in addition to complete
documentation duty. It's also a possibility that this could be used to
enumerate test coverage for server implementation.
Using this functionality, we've also developed a template to automatically
generate and API specification for submission into docker core.
As a baseline for the new registry API specification, we are checking in the
proposal as currently covered in docker/docker#9015. This will allow us to
trace the process of transforming the proposal into a specification. The goal
is to use api descriptors to generate templated documentation into SPEC.md. The
resulting product will be submitted into docker core as part of the client PR.
