Personally, I don't care about REST, I never did. However this made me giggle:
> "REST offers better compatibility. How so? Why do so many REST webservices have “/v2/” or “/v3/” in their base URLs then? Backwards and forward compatible APIs are not hard to achieve, with high level languages, as long as simple rules are followed when adding/deprecating parameters. As far as I know, REST doesn’t bring anything new on the subject."
The author has a serious misunderstanding about what backwards compatibility or lack thereof means.
That APIs end up with "/v2" and "/v3" in their endpoints, that's absolutely the right approach for backwards compatibility, as long as the previous version of the API stays online and continues to be supported.
Backwards incompatible evolution means breakage. No matter what features you like to add or change, by introducing backwards incompatible changes you're going to break people's software and that's never a good thing.
The author is also naive in thinking that there can exist "simple rules for deprecating parameters". There's no such thing. Nobody pays attention to your service announcements or policies unless their software breaks.
Also "high level programming languages" have absolutely nothing to say on this matter. Yes, it's simpler to update a library that breaks compatibility within a statically typed language, but that will still come after the software breaks due to the network protocol being changed, implies active maintenance with associated costs and mainstream languages have no facilities to efficiently describe network level protocols.
> "REST offers better compatibility. How so? Why do so many REST webservices have “/v2/” or “/v3/” in their base URLs then? Backwards and forward compatible APIs are not hard to achieve, with high level languages, as long as simple rules are followed when adding/deprecating parameters. As far as I know, REST doesn’t bring anything new on the subject."
The author has a serious misunderstanding about what backwards compatibility or lack thereof means.
That APIs end up with "/v2" and "/v3" in their endpoints, that's absolutely the right approach for backwards compatibility, as long as the previous version of the API stays online and continues to be supported.
Backwards incompatible evolution means breakage. No matter what features you like to add or change, by introducing backwards incompatible changes you're going to break people's software and that's never a good thing.
The author is also naive in thinking that there can exist "simple rules for deprecating parameters". There's no such thing. Nobody pays attention to your service announcements or policies unless their software breaks.
Also "high level programming languages" have absolutely nothing to say on this matter. Yes, it's simpler to update a library that breaks compatibility within a statically typed language, but that will still come after the software breaks due to the network protocol being changed, implies active maintenance with associated costs and mainstream languages have no facilities to efficiently describe network level protocols.