re: Real World Developer's Problems: API Versioning VIEW POST

TOP OF THREAD FULL DISCUSSION
re: My point was that there is no need to anticipate such world-breaking changes with a version ID. We have the hostname for that. What you are creatin...
 

You missed the end of the sentence: "...but a new system with a new brand" :-)
It seems just a detail, but is fundamental, instead.

Fielding is not saying that a new version is a new system. He is talking about a totally different system, different just like dev.to and medium.com.

The point is: when do you really need a new system when your API is true RESTful?

Read the sentence just after the one you mentioned:

On the Web, we call that a new website. Websites don’t come with version numbers attached because they never need to. Neither should a RESTful API. A RESTful API (done right) is just a website

Basically, a REST client should only know the entry URI of your (true) RESTful APIs. If you change the signature or the organization of your APIs, your client should be able to discover them without need to specify a version.

Indeed, in a true RESTful context, each resource must have the URIs of any related resources. Again, the client should know just the initial URI of your APIs. The other URIs must be dynamically discovered: basically this is the meaning of State Transfer in the REST acronym.

I didn't miss it, I deliberately omitted it, because it's only semantics. Different system or version is just a question of perspective here.

The only thing Fielding has to say about this problem: Either you never break backward compatibility or you are not doing REST. If you want to do REST, create a new API every time you would break backward compatibility.

He's only unhappy with the fact that some people call these new non-backward compatible systems "new major version" and not "new systems".

GTA isn't GTA3 etc.

code of conduct - report abuse