This is the fourth post in this series of posts on RESTful web service.
Part 1, Part 2, Part 3
In this post we discuss the need for versioning an API and the possible ways to do it. The need for versioning is not restricted to the REST scenario alone - whatever is applicable to the REST scenario is also applicable to HTTP web services.
APIs don't exist for themselves - they are meant to be consumed by clients. When an API is considered stable and shipped to production, a client consuming the API buys into the media type and the representation of the resources it describes. Now if the API was to undergo a change - and it will, as change is the only constant in our industry - its clients' will in all probability break.
This is the fundamental reason to version APIs.
Read the full post here.
Part 1, Part 2, Part 3
In this post we discuss the need for versioning an API and the possible ways to do it. The need for versioning is not restricted to the REST scenario alone - whatever is applicable to the REST scenario is also applicable to HTTP web services.
APIs don't exist for themselves - they are meant to be consumed by clients. When an API is considered stable and shipped to production, a client consuming the API buys into the media type and the representation of the resources it describes. Now if the API was to undergo a change - and it will, as change is the only constant in our industry - its clients' will in all probability break.
This is the fundamental reason to version APIs.
Read the full post here.
