Reputation: 5146
I have a REST service with version v1 running fine in production. Now I need to make version v2 url as the response format is changed so we don't want to affect our current customers who are using v1 url. We will be returning some other object back with version v2 url instead of using ClientResponse
object.
Below is my current design in which version is provided in @Path annotation. This was done by somebody else who left our team.
@Component
@Scope("request")
@Path("/abc/hello/v1")
public class ClientService {
// ... some variables
@GET
@Path("/json/line")
@Produces(MediaType.APPLICATION_JSON)
public ClientResponse getLineData(@Context UriInfo uriInfo) {
}
}
What is the best way to design version v2 url here? Should I just make a new class and have @Path
as @Path("/abc/hello/v2")
like this and copy paste everything in it? Or should I create some abstract class and have ClientServiceV1
extend that abstract class and then have ClientServiceV2
extend that abstract class as well? How should I proceed?
Upvotes: 0
Views: 943
Reputation: 41240
My strategy for versioning REST API is to not let JAX-RS runtime automatically determine what REST resources to load and instead explicitly state them in the java.ws.rs.Application
implementation.
My java.ws.rs.Application
implementation is where I do the versioning and I state it there the base API URI
@javax.ws.rs.ApplicationPath("v1")
public class MyAppV1 extends java.ws.rs.Application {
Set<Class<?>> getClasses() {
return new java.util.HashSet<>(java.util.Arrays.asList(
ClientService.class,
OtherService.class));
}
}
And then create another one for "v2" where I start adding my components there.
The intent of it is I can have multiple versions present and I can deprecate the old ones and eventually remove them as needed. It also allows me to reuse the existing services.
However, if your existing services are suffixed with "v1" then you may want to either duplicate the code or make it point to the new version depending on your needs.
Upvotes: 2