> While I agree that I'd rather not see a version number in URIs if I
> don't have to, I don't think there's much of a moral difference
> between /api/vN/... and {/api/..., /apivN/...}. Both end up with
> version numbers in the URI local-part components, with the second
> case avoiding them only for the first version — hardly a huge win.
There is no technical difference, but there is a big difference in signaling.
/api/v1 is just an affordance that is inviting you to exercise it.
As in “This protocol is designed to have many incompatible versions”.
There is a strong tendency of trying to transfer the experience from software versions to protocol versions. The former are useful (and there is a de-facto standard for how to handle the numbering), the latter rarely are — a “protocol version” is mainly there to prevent communication (and even in the cases where the original design was actually considering evolution, the deployment experience often still is exactly that).
> Or register and use a new header to communicate version numbers. Maybe
> we should have standard, generic API version negotiation/indication
> headers?
I hope not.
Kick the habit. Stop thinking in versions. There are better ways to handle evolution.
Grüße, Carsten
