Open robhaswell opened 9 years ago
:+1: - I very much agree with this sentence:
"Being able to take advantage of current HTTP routers would make plugin authorship easier."
@binocarlos your use-case was in mind when you wrote that :) I'm not yet ready to +1 this, I am on the fence and would enjoy some more argument. @progrium?
Again, no technical reason other than one is clearly simpler and when there are two options that both solve a problem, you should always pick the simpler one. So it not only makes the author experience easier, and makes the spec and implementation slightly simpler, but it further reduces the need for structured meta-data in the body, which will further simplify the spec and has its own technical merits.
@progrium has proposed (via email) removing the Docker request path from the JSON encoded body, and encoding it in the HTTP request path. This would mean that a request for
GET /v16/containers/json
to Docker would be proxied to an Adapter defined ahttp://adapter/
at the URIhttp://adapter/v16/containers/json
.Note that currently the method would always be POST, as the body encodes the details of the request.
While there are no technical arguments for this request, there is a good practical argument. The process of parsing a request path and passing it off to a handler function, known as HTTP routing, is a solved problem. Being able to take advantage of current HTTP routers would make plugin authorship easier.