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 creating is not a new version of the API, but a new system...
If you look at constraints of SemVer, a new version is basically that, a new system that doesn't try to be compatible with older clients.
If his point is "you do a new system, get a new hostname" the chain of arguments is simple.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you look at constraints of SemVer, a new version is basically that, a new system that doesn't try to be compatible with older clients.
If his point is "you do a new system, get a new hostname" the chain of arguments is simple.
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:
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.