4 ms·
Putting the version in a header looks "elegant" at first, as it keeps one URL for one resource. But in reality it adds accidental annoyance with no benefits ove
by ProblemFactory 5y ago
Putting the version in a header looks "elegant" at first, as it keeps one URL for one resource. But in reality it adds accidental annoyance with no benefits over having the version somewhere in the URL.
* Have to set up response headers and caching carefully to make sure different versions are cached separately.
* A bit of extra complexity to set up load balancing.
* A bit of extra complexity to set up web framework routing to controllers.
* A bit of extra complexity for logging to track which endpoints were called.
* Calling the URL without specifying a version gets you some undefined version...
* ... or if you require a version header, can't preview GET endpoints in a standard browser.
* If different parts of the API have different latest versions, you can't encode it in an URL and therefore can't return URLs for linking between resources.
* On major version changes you might be removing, renaming or moving URLs, so why keep them pure and versionless in the first place.
- jayd16 5y agoStill seems like caching is the only real issue. The complexity of dealing with headers seems easier than the complexity of routing constantly changing urls.
- iudqnolq 5y agoBlows up a smaller percentage of the time when you forget it is often worse. How often are your APIs changing incompatibly anyway? When they do changing the URL should dwarf next to changing the surrounding code to the new data model. If that's not the case then what was the point of the upgrade?
- jayd16 5y agoMy point is its pretty trivial either way. With headers, you can use the stripe style[1] time stamp version headers that give you a clearer picture of exactly targeting an API as it was at any given time, instead of as it was stated in the url (ie .../vN/...) [1]https://stripe.com/docs/api/versioning https://stripe.com/docs/api/versioning