Add support to a REST API

[marcellodesales]

The app should support a REST API...

• Repositories: http://server/docker-registry-web/repositories?format=json

Should render:

{ [ { id: 0, hostname: "http://register1.corp.example.com", images: ["user1/app:version1", "user1/app2:version2", "user3/app1:latest"] }, { id: 1, hostname: "http://register2.corp.example.com", images: ["user5/app4:latest", "myself/app2:version2", "user3/app1:latest"] } ] }

• Repository: http://server/docker-registry-web/repositories/0?format=json

{ id: 0, hostname: "http://register1.corp.example.com", images: ["user1/app:version1", "user1/app2:version2", "user3/app1:latest"] },

And so on... The idea here is to be able to use this API programmatically and be able to integrate it with other systems.

[atcol]

Good suggestion, I can mostly see a use case where you could programmatically add or read configuration from Docker Registry Web for registries. Manipulating the docker side of things should be done directly through to the registry instance in question.

[marcellodesales]

Yeah, that's exactly what I'm looking for!!! However, manipulating the docker side of things may be useful for things like "Updating image metadata such as description, and any metadata we want to annotate images with". So, no matter where the image goes, its metadata will always be available, even if it's a link to a resource...

Anyway, we can shoot for being on Richardson Maturity Model Level 2 http://martinfowler.com/articles/richardsonMaturityModel.html... Descriptions on the design are here https://restful-api-design.readthedocs.org/en/latest/methods.html, and lots of API examples/discussions at http://blog.2partsmagic.com/restful-uri-design/.

Here's a high level requirements list, IMO. For collections, we should consider size limit per request, pagination, search queries based on the entry object property values, etc. As usual, HEAD is useful for caching data without retrieving the body.

• Registry Collection: http://server/docker-registry-web/registries
  • GET: Retrieve list of registries
  • POST: Adds a new registry
  • HEAD: Header with meta-information (Same as GET, along with Content-Length, Content-MD5, ETag or Last-Modified...)
  • DELETE (optional): Can take a list of registries to be deleted
  • PUT / PATCH (optional): Can take a list of registries to be updated
• Registry Resource: http://server/docker-registry-web/registries/{id}
  • GET: Retrieve the info for Registry {id}
  • PUT / PATCH: Updates the info for Registry {id}
  • DELETE: Deletes Registry {id}
• Repository Collection (Global): http://server/docker-registry-web/repositories
  • GET: Retrieve the lists all the repos indexed by Registries (similar output to the current UI version)
• Repository Collection (Registry): http://server/docker-registry-web/registries/{id}/repositories
  • GET: Retrieve the list all the repos by Registry {id} (similar output to the current UI version)
  • HEAD: Header with meta-information (Same as GET, along with Content-Length, Content-MD5, ETag or Last-Modified...)
• Repository Resource: http://server/docker-registry-web/registries/{id_1}/repositories/{id_2}
  • GET: Retrieve the info about the repo {id_2} from the Registry {id_1} (similar output to the current UI version).
  • HEAD: Header with meta-information (Same as GET, along with Content-Length, Content-MD5, ETag or Last-Modified...)

[atcol]

I like it. Let's concentrate on Registry configuration first and start developing the REST API from there. Want to start looking at it?

I'll move to a later release.

[marcellodesales]

@atc- Awesome...! What's the "Registry configuration" issue #? I can definitely help out on both...

[atcol]

I meant start exposing just the Registry configuration (URL, scheme, etc) via this REST API, then see how it "feels" and whether we need more.

[marcellodesales]

:+1: That's a feature that will help a lot!!! Thanks for starting working on it!

[deardooley]

Does it make sense to replicate the existing docker registry and hub APIs for compatibility. Might be a nice step towards an OSS registry ui. Also might fix some of the headaches with the current registry apis such as lack of usage info, extensive metadata, and ACL