Conversation
Closes moby#21157 Signed-off-by: Ben Firshman <[email protected]>
|
How do we prevent breaking existing API consumers which aren't using an explicit version? |
Which is the default for… a whole lot of third-party library 😰 |
|
I guess the point is that this forces them to fix their libraries. Perhaps we could open PRs against all the popular libraries in advance of the version of Docker that this is included in. To smooth the transition, perhaps the 404 could return a useful error message. ("In version 1.25 of the API, it is now required to specify the version number. Prefix the URL with v1.25, or if you're using a client library, you may need to upgrade your library.") |
|
We're removing a feature, we need to follow the deprecation policy. |
|
Yes, I suppose removing the bit which isn't versioned is removing a feature. I'll open another PR updating the documentation to say it is deprecated, along with all of the bits which add the version number to example requests. I wonder if there is a way we could add a deprecation notice to the API response... |
|
Opened a new PR for just deprecation, because it's useful to keep this around as an example of implementing it for when that needs to be done in the future: #27830 |
See moby#21157 for more details. In a future version of Docker, providing a version to API calls will be mandatory. An implementation of this is in moby#27801. Signed-off-by: Ben Firshman <[email protected]>
See moby#21157 for more details. In a future version of Docker, providing a version to API calls will be mandatory. An implementation of this is in moby#27801. Signed-off-by: Ben Firshman <[email protected]>
4 participants
- What I did
This makes the version in API URLs mandatory. Calling a URL without the version (e.g.
GET /containers/json) will return a 404.See #21157 for more information.
- Description for the changelog
The API version is now required in all API calls. Instead of just requesting, for example, the URL
/containers/json, you must now request/v1.25/containers/json.