endpoint evolution
- Given I have an existing web service application with consumers
- And I have a request to modify/update an endpoint to return new content
- Then I have an obligation to my existing consumers to not break their contract
- And still provide the new content
There’s a few ways to do this. Once common pattern is thru versioning in the resource path:
I think a more elegant and effective way to do this is thru Content Negotiation.
This is where I provision an endpoint to return content based on what the user requests, while providing a default case.
Here’s an example of this pattern using Spring Boot:
In this endpoint we have two @RequestMapping
s to the same root path.
The top one is our initial endpoint. It returns a simple list of Doubles.
The v2 version is a breaking change - it returns a list of SensorReading
instances. Any consumers expecting a list of Doubles would be broken.
Lucky, by specifying the type of content our endpoint produces, Spring is able to help us out and return what the consumers requests via the standard HTTP Accept
header, defaulting to the initial endpoint.
Usage:
Same endpoint, different content, no breaking changes. Ship it!