4 ms·
I'd recommend against using `v1` in the path and prefer content negotiation: GET /resource/1 Accept-Version: ~1.0.2 ... Implementation-wise this e
by agentultra 6y ago
I'd recommend against using `v1` in the path and prefer content negotiation:
GET /resource/1
Accept-Version: ~1.0.2
...
Implementation-wise this ends up with better code (and less code) on the back-end and a reduced number of HTTP routes (which should represent the entities and be maintained).
The pain of REST is that there's very little in terms of "correct" as we don't have a formal specification of the semantics. If you end up using /v1 it's not any more or less REST-ful.
- idlewords 6y agoI'd recommend the opposite, as with a versioned URL you can very easily route stuff to different machines by simple URL inspection and have a very clean separation between versions.
- dnautics 6y agoUnless you're talking about a human dispatching the request (url toolbar or via tool like curl) There's nothing special between a url path or a content header Either way it's layer 7 routing. What was the advantage again?
- packetlost 6y agoLoad balancers/reverse proxy have first-class support for routing based on paths, but support for routing based on headers is trickier or not possible depending on the software.
- wtetzner 6y agoI think they're useful for different things. Media-type versioning is useful for supporting different data types/representations of the same resource. URL versioning is useful for versioning resources themselves and their behavior/business logic.
- pkulak 6y agoI dunno. We started doing something like that at my company (we actually use the plain Accept/Content-Type headers, so "application/vnd.mycompany.service.v1+json") and it's been a giant pain. Routing based on headers sounds cool, but basically no backend OR frontend frameworks support it well. Even if they say they support, there are bugs or weird traps to fall into. Path versioning is just so much easier for everyone.