> You are not expected to parse 'docker ps' output programatically.
I see that my particular pet peeve (there's no name or link information in `docker inspect`) has been fixed. Nice! Still, I can't imagine the thought process that leads to express links in JSON as `["/foo:/bar/foo","/baz:/bar/baz"]` rather than `{"foo":"foo","baz":"baz"}` (or even `{"/bar/foo":"/foo","/bar/baz":"/baz"}` if you're attached to the weird hierarchical names). I similarly cannot imagine reasoning that leads to providing port number in JSON as a string, with prefix.
>> Is it still Docker's official position that CLI is only official interface, and using HTTP API is frowned upon?
> That was never true. I'm not sure how you got that idea.
Cannot find it now: it's not easy to google out (and if it was in the docs, I'd need to go through web.archive.org), and I didn't think about archiving it myself for later use. I think this was either in (possibly earlier version of) docs, or in some GitHub issue. The sentiment seems to stand, though: Docker's own code base doesn't even include any usable API client, and many seemingly basic CLI operations are very convoluted in API (how do I `docker run` with API? Is it still split across at least two separate calls?). Some of these problems are echoed in https://github.com/docker/docker/issues/7358
Some (possibly most of all - I certainly hope so!) are solved, but the API docs were good at listing the endpoints and (some of) the parameters [I recall JSON format was incompletely described, or not kept up to date]. There was virtually no pragmatic docs on how to use the API to achieve equivalent of, say, a `docker run` invocation. And while I obviously can open an issue or fix it in a PR, reflecting problems back at community because it's open source, if it bothers you, go fix it yourself doesn't seem a proper approach. In particular, if the problem is about keeping documentation in sync with code (format of JSON described in API docs did at some point diverge from actual behaviour; if you want me to go through the docs right now and verify each piece, I'd be happy to do that, but let's discuss the consulting contract first), it's not reasonable to expect your users to pinpoint the issue by going through Git changelogs.
> You can use all these things [HTTP Auth] with the registry API.
Can I `docker pull` an image that is behind plain http auth (e.g. at a registry proxied to https://foo:bar@example.com/)? How do I specify that? Last time I tried to figure this out (before 1.2.0, after 1.0.0, so it may have changed), this was either not possible, or completely undocumented.
And while we're at it, what would exactly be the problem with letting me pull an image available at https://foo.bar@example.com/path/to/image.tar? Why there even is a separate registry API rather than plain HTTP? This part still eludes me.
Re tcp://… vs http://… it's obviously functionally equivalent and cosmetic, unless you want to write some plumbing and you have to add logic to translate from the tcp:// format (which doesn't seem to have any actual reason to be written this way) to http:// URL and back. Similar thing with `tcp://` prefix for ports forwarded from linked containers: I either have to use the long form that includes the original port number, or parse out the irrelevant `tcp://` piece (yes, I know there could be udp:// [but why the double slash? is there any URI path that could follow?]; the protocol is usually obvious from the context, and need to parse out the irrelevant text is actual overhead).
So, for Docker's convenience (or because of a bit of thoughtlessness when something was first implemented), there's a small but significant overhead incurred on a lot of current and future pieces of plumbing and containers, because for some reason (was there any?) you decided `tcp://` looks better than `http://` for an HTTP URL, and `tcp://1.2.3.4:567` looks prettier than just `1.2.3.4:567`.
I see that my particular pet peeve (there's no name or link information in `docker inspect`) has been fixed. Nice! Still, I can't imagine the thought process that leads to express links in JSON as `["/foo:/bar/foo","/baz:/bar/baz"]` rather than `{"foo":"foo","baz":"baz"}` (or even `{"/bar/foo":"/foo","/bar/baz":"/baz"}` if you're attached to the weird hierarchical names). I similarly cannot imagine reasoning that leads to providing port number in JSON as a string, with prefix.
>> Is it still Docker's official position that CLI is only official interface, and using HTTP API is frowned upon? > That was never true. I'm not sure how you got that idea.
Cannot find it now: it's not easy to google out (and if it was in the docs, I'd need to go through web.archive.org), and I didn't think about archiving it myself for later use. I think this was either in (possibly earlier version of) docs, or in some GitHub issue. The sentiment seems to stand, though: Docker's own code base doesn't even include any usable API client, and many seemingly basic CLI operations are very convoluted in API (how do I `docker run` with API? Is it still split across at least two separate calls?). Some of these problems are echoed in https://github.com/docker/docker/issues/7358
Some (possibly most of all - I certainly hope so!) are solved, but the API docs were good at listing the endpoints and (some of) the parameters [I recall JSON format was incompletely described, or not kept up to date]. There was virtually no pragmatic docs on how to use the API to achieve equivalent of, say, a `docker run` invocation. And while I obviously can open an issue or fix it in a PR, reflecting problems back at community because it's open source, if it bothers you, go fix it yourself doesn't seem a proper approach. In particular, if the problem is about keeping documentation in sync with code (format of JSON described in API docs did at some point diverge from actual behaviour; if you want me to go through the docs right now and verify each piece, I'd be happy to do that, but let's discuss the consulting contract first), it's not reasonable to expect your users to pinpoint the issue by going through Git changelogs.
> You can use all these things [HTTP Auth] with the registry API.
Can I `docker pull` an image that is behind plain http auth (e.g. at a registry proxied to https://foo:bar@example.com/)? How do I specify that? Last time I tried to figure this out (before 1.2.0, after 1.0.0, so it may have changed), this was either not possible, or completely undocumented.
And while we're at it, what would exactly be the problem with letting me pull an image available at https://foo.bar@example.com/path/to/image.tar? Why there even is a separate registry API rather than plain HTTP? This part still eludes me.
Re tcp://… vs http://… it's obviously functionally equivalent and cosmetic, unless you want to write some plumbing and you have to add logic to translate from the tcp:// format (which doesn't seem to have any actual reason to be written this way) to http:// URL and back. Similar thing with `tcp://` prefix for ports forwarded from linked containers: I either have to use the long form that includes the original port number, or parse out the irrelevant `tcp://` piece (yes, I know there could be udp:// [but why the double slash? is there any URI path that could follow?]; the protocol is usually obvious from the context, and need to parse out the irrelevant text is actual overhead).
So, for Docker's convenience (or because of a bit of thoughtlessness when something was first implemented), there's a small but significant overhead incurred on a lot of current and future pieces of plumbing and containers, because for some reason (was there any?) you decided `tcp://` looks better than `http://` for an HTTP URL, and `tcp://1.2.3.4:567` looks prettier than just `1.2.3.4:567`.