-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a "Versioning" section to the Agency spec as in the Provider spec #422
Labels
Agency
Specific to the Agency API
enhancement
New feature or request
Policy
Specific to the Policy API
Comments
Hi @sarob, this issue should be labeled "Agency" |
Agreed, I'll update Agency and Policy in the 0.4.1 timeframe. Thanks @sarob. |
@Karcass have you made any progress? I would be happy to help. |
@Retzoh I have not, I have been heads-down on the Agency/Provider naming reconciliation. If you want to take a swing at it, please do! |
I will propose a PR this week. |
This was referenced Feb 6, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Agency
Specific to the Agency API
enhancement
New feature or request
Policy
Specific to the Policy API
Is your feature request related to a problem? Please describe.
There is no specification on how versioning works for the Agency API :
A provider cannot specify the version used for the data he is trying to push.
Describe the solution you'd like
For consistency, I propose to use the provider API versioning system, where the version used is specified in the request Accept header.
If we re-use the
application/vnd.mds.provider+json
media-type or rename it toapplication/vnd.mds+json
in the provider spec, we could easily centralise the versioning spec in one place and expand it to further APIs.Is this a breaking change
A breaking change would require consumers or implementors of the API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).
We can decide to make it breaking or not :
Adding implicit support for the previous minor version like in the provider spec makes it non-breaking :
This would stay consitent with the two concurrent version support from the release guidelines.
Enforcing this retro-actively would make it breaking.
Impacted Spec
For which spec is this feature being requested?
agency
: yespolicy
: we could add it there too, so a provider requesting the API can ask for a specific version in returnDescribe alternatives you've considered
The classic alternative would be to enforce a version number in URLs.
But this would be inconsistent with the provider spec and so far, MDS does not put constrains on API URLs outside from the endpoint and query-parameters.
Additional context
None
The text was updated successfully, but these errors were encountered: