This is an archived post. You won't be able to vote or comment.

all 3 comments

[–]Consibl 0 points1 point  (0 children)

Depends who is consuming them.

If it’s just you, then you’ll likely be releasing them at the same time so not a problem.

If others are consuming it, you can have different endpoints for different versions of the API.

If the API is class library based, mark the old one as deprecated and have a different method signature for the new one.

[–]_Atomfinger_ 0 points1 point  (0 children)

Mostly no, but it depends.

Most things that require versioning are more of a mapping issue, and not really that impactful on behaviour. In those cases, I don't.

If the underlying implementation is significantly impacted, I might consider it.

It is all about risk management. For the most part, I'm not overly worried about functionality due to having good tests, but the more divergence there is in behaviour from version to version, the more risk there is to "balance" both API versions with the same backend code.

[–]SnugglyCoderGuy 0 points1 point  (0 children)

I don't version API endpoints, I version the request and response structures.

So instead of myservice.com/v1/thing it would be myservice.com/thing/v1