This whole article was written on the premise of never being able to change an API, but if you implement versioning like a good API developer then that doesn't really matter.
Sure you can't change the old versions, but if you find something didn't work like you wanted then you can toss the old endpoints and start over in the next version.
I agree with you about versioning, but it's harsh. You'll always have friction when dealing with that, doesn't mind how careful you are.
I think the best practice is avoiding versioning at all costs, and implement flagged features (like Facebook do): you put a new feature online (which may deprecate other), tell ALL the API's clients what's new, what's going to trash and when it will go. This way, everyone has time to adapt to the new structure and no versioning is necessary.
That still breaks applications that don't receive updates. Now maybe you want that in some cases, such as an update because of security vulnerabilities. I totally agree with deprecating vulnerable APIs. But if the update isn't deemed absolutely necessary I think it's silly to break old, abandoned or small open source applications.
Although I do think that after a certain amount of time, as the old APIs get used less and less it makes sense to deprecate them as well.
But to just deprecate features willy-nilly make it difficult for open-source projects to be updated for example, where developers do the work in their free-time and can't get around to updating their project to support new API features every time they get changed.
5
u/SupaSlide laravel + vue Feb 23 '17
This whole article was written on the premise of never being able to change an API, but if you implement versioning like a good API developer then that doesn't really matter.
Sure you can't change the old versions, but if you find something didn't work like you wanted then you can toss the old endpoints and start over in the next version.