1

I have a server REST API in java. The version 1.0 of the server code basically performed some functions and then use to return object of a class say X to client 1. Now in current version 2.0 same server code returns Response class object to client 2. Please note the API versioning is not done here. It is exactly the same code only difference is that some new features were added as server for client 2 didn't need some heavy features that were there in server 1. The issue is that I merging both 1.0 and 2.0 and creating a single binary. I have merged everything including functionality but the issue is in return types. Please note that url end point for all clients sides will be same and client side code can't be changed. Hence is there any way that this API can return two different response objects at run time according to the type of clients?? Also the server API can easily identify client type before returning the response but not when it gets the request.

Version 1 of server Code:

   @POST
    public T createOne(@BeanParam L locator, T item, @Context HttpServletRequest httpServletRequest, @Context HttpServletResponse httpServletResponse) { }

Version 2 of server code:

    @POST
    public Response createOne(@BeanParam L locator, T item, @Context HttpServletRequest httpServletRequest, @Context HttpServletResponse httpServletResponse) { }

Please note that the URI is exactly the same and I don't want to version it.

Vikas Rai
  • 87
  • 12
  • `public Object createOne(...)`!? – luk2302 Sep 09 '19 at 10:21
  • @luk2302 The problem is in return types not in passing arguments. – Vikas Rai Sep 09 '19 at 10:24
  • ... which is why I changed the return type to `Object`. – luk2302 Sep 09 '19 at 10:25
  • @luk2302 I am sorry you are right. However the clients would be expecting type T (client 1) and Response class type(type 2). So will this work without changing client side expected return type code?? Also please note that for client1 the T type in return type is same as the T type in the request parameter. So in request if it passed object of class A it expects return type to be object of type A only. – Vikas Rai Sep 09 '19 at 10:32
  • The clients of a REST-API don't expect T, they (hopefully) expect Json, which does not have a type. Note that the *value* you return might still be a `T` or a `Response`, but the type you *declare* is `Object`. The return type of a rest API does not matter much anyway because it should be converted to something like Json. – luk2302 Sep 09 '19 at 10:57
  • See also https://stackoverflow.com/questions/389169/best-practices-for-api-versioning – Raedwald Sep 09 '19 at 12:07
  • See also https://stackoverflow.com/questions/972226/how-to-version-rest-uris – Raedwald Sep 09 '19 at 12:08
  • See https://stackoverflow.com/questions/18905335/rest-versioning-url-vs-header – Raedwald Sep 09 '19 at 12:09
  • Use content negotiation via the `Accept` header to divert calls to different end point methods. – Raedwald Sep 09 '19 at 12:13
  • @Raedwald: Please note I am not talking about REST API versioning. That is something I don't want to do. I need to have exactly same URL and same headers. Hence please consider this issue and help me resolve this. – Vikas Rai Sep 09 '19 at 15:21
  • If different *clients* are using different *versions* of your API, you **are** trying to do versioning of your API. Typically this makes use of `Accept` headers. But you could use other headers, such as `User-Agent`. – Raedwald Sep 09 '19 at 16:11
  • If you do not beleive this question is a duplicate, edit your question to include a link to the other question and explain in your question *why* it is not a duplicate. – Raedwald Sep 09 '19 at 16:13

0 Answers0