2 ms·

No one had a strong opinion on simplicity of “/foo/v2” vs “/foo” with a header variable of “2022-11-28.” That seems really surprising.

Gigachad 4y ago
A strong argument is different from a strong opinion. Sounds like there are lots of people who feel strongly but none of them can put up a strong argument showing why one is better than the other.
- prepend 4y ago
  Simplicity is a pretty strong argument in my mind. This whole thread has been full of arguments against. Not sure how we settle on if they are strong enough. It seems not strong enough for Microsoft. But that’s why I was surprised as being a not very useful hassle would seem to be a big reason not to do it that way. Cynically, I fear this method allows lots more versions and lots more breaking changes so get ready for stuff that could have been backwards compatible now just be a breaking change with a new version.
  - masklinn 4y ago
    > Simplicity is a pretty strong argument in my mind. But the URL version inly wins that argument if you ignore all the issues. Github clearly wants to iterate their REST API faster and feels constrained, the URL method would mean either the entire API versions over quickly with almost but not quite copy pastes, or endpoints get versioned individually and you’re simultaneously hitting /3/foo and /42/bar with little rhyme or reason. Things get confusing when you retrieve an entity via /6/ then update it via /4/.
grey-area 4y ago
For end users the api should be effectively versionless (i.e backwards compatible in all possible cases). Most api consumers don’t care if fields are added or new methods added they are not using, thus they don’t care much about the version unless upgrading. Removing things or changing behaviour should be very rare and have a very good justification.

2 ms·

No one had a strong opinion on simplicity of “/foo/v2” vs “/foo” with a header variable of “2022-11-28.” That seems really surprising.

by prepend 4y ago

Gigachad 4y ago
A strong argument is different from a strong opinion. Sounds like there are lots of people who feel strongly but none of them can put up a strong argument showing why one is better than the other.
- prepend 4y ago
  Simplicity is a pretty strong argument in my mind. This whole thread has been full of arguments against. Not sure how we settle on if they are strong enough. It seems not strong enough for Microsoft. But that’s why I was surprised as being a not very useful hassle would seem to be a big reason not to do it that way. Cynically, I fear this method allows lots more versions and lots more breaking changes so get ready for stuff that could have been backwards compatible now just be a breaking change with a new version.
  - masklinn 4y ago
    > Simplicity is a pretty strong argument in my mind. But the URL version inly wins that argument if you ignore all the issues. Github clearly wants to iterate their REST API faster and feels constrained, the URL method would mean either the entire API versions over quickly with almost but not quite copy pastes, or endpoints get versioned individually and you’re simultaneously hitting /3/foo and /42/bar with little rhyme or reason. Things get confusing when you retrieve an entity via /6/ then update it via /4/.
grey-area 4y ago
For end users the api should be effectively versionless (i.e backwards compatible in all possible cases). Most api consumers don’t care if fields are added or new methods added they are not using, thus they don’t care much about the version unless upgrading. Removing things or changing behaviour should be very rare and have a very good justification.