Just say no – to versioning APIs
redahmeid.comI think they misunderstand the purpose of the version signal across the protocol: if signals if a boundary point for api action can't do (only) what it used to do, it signals what might happen next.
If v1.0 is deployed, does it subsume v0.9 (augment) or does it invalidate? At least two different outcomes. Now, analyse by actor: what could an initiator do, what could a responder do? Probably two or three choices. It's heading to a potential combinatorial explosion of pairs of behaviour across the sender/respondent barrier, both independent actors.. So, define each side, and limit this space but keep the version signalling to drive the decision logic.
I think the original author gets this but proposes a rigid outcome. Well, sorry, but there are choices.
Look at how zfs signals extensions and their effect on mutable state in the FS. Or, NFS
Hi. I wrote the post. Thank you for your comment, what you say makes sense.
I think my point is that the decision logic doesn't need to be signalled. As long as contracts are respected what the decision logic is should be pretty irrelevant.
However, your examples of zfs and NFS are pertinent. I was tempted to address that point too and express the difference between those examples and web based distributed APIs. I had hoped it was clear in the post what sort of APIs being addressed. Maybe not. Saying that, though I haven't thought about it a lot, it would be an interesting thought experiment to figure out how all versioning can be removed.
Either way, thanks for the comment.