How to create generic java code to make REST api calls ?

I have some automated rest api tests in Java. They use a proprietary java library (restLibOne) to make rest api calls. The proprietary library is similar in concept to rest assured, but vastly different from it in terms of how it makes api calls. Now, there is another proprietary library, restLibTwo which will replace restLibOne and is vastly different from it. Who knows in the future there will be yet another replacement.

I need to convert the code to use restLibTwo instead of restLibOne. I am not sure how to approach this project but I have an idea. I want to start by making some "generic" class which represents how rest api calls are made. Then, the functions in this class will use any library to make those calls. For example :

public class GenericRestApiCallMaker { public static SomeKindOfResponseObject makeGetCall(param1, param2, param3...) { //Call any library like restassured to make the call and return SomeKindOfResponseObject return SomeKindOfResponseObject; } public static Object makePutCall() {} public static Object makePostCall() {} public static Object makeDeleteCall() {} public static void sampleTestCode() { SomeKindOfResponseObject response = GenericRestApiCallMaker.makeGetCall(arg1, arg2, arg3...); response.getReturnCode(); response.getBody(); response.getHeaders(); response.whatElseCanIGet(); } }


The problem is that I don't know how to design functions to make rest api calls.  I don't know what all inputs are needed to make api calls besides simple inputs like url, headers, method, body etc. So, I don't know what arguments my api call making functions should have.
Then, I don't know what all things a response must have besides the simple ones like code, headers, body etc. So, I don't know what kind of object should be returned by my api call making functions.

Is there already a generic class/code which does what I want ? If not, then how should I go about designing my own class ? Is this project best given to someone who is an expert in api automation ?

Thanks in advance !

I'm confused. If you already have code that uses restLibOne, that should provide a good idea of what parameters are needed, and how to handle inputs and outputs, no?

Also, is there no documentation for restLibTwo? If they expect you to use it, they should tell you how to do that, no?

Tim Moores wrote:I'm confused. If you already have code that uses restLibOne, that should provide a good idea of what parameters are needed, and how to handle inputs and outputs, no?

Also, is there no documentation for restLibTwo? If they expect you to use it, they should tell you how to do that, no?

Yes. But, I want to make some kind of a wrapper class which will provide a constant/never changing interface for making rest api calls. Then, this wrapper is free to use any library to make the api calls, whether it be rest-assured, apache httpclient, our proprietary libraries.
By the way, I got some answers to this question here - https://sqa.stackexchange.com/questions/38003/how-to-create-generic-java-code-to-make-rest-api-calls

What do you think about them ?

It sounds like you want to write code to work with any kind of REST API whatsoever, but you don't know what all of those APIs do. If that's what your question means, then you're going about it backwards. You can't write an interface to an API which you don't understand. So your approach should be to document how those APIs work and then start writing code to interface with them. I'm making those statements based on what you said:

The problem is that I don't know how to design functions to make rest api calls.  I don't know what all inputs are needed to make api calls besides simple inputs like url, headers, method, body etc. So, I don't know what arguments my api call making functions should have.

To me that sounds like you need to find out those things before trying to write the Universal REST API Caller. Start with one API, then look at another API and see what's different and what you missed, then look at another API and refactor when you find your code is becoming a mess.

Paul Clapham wrote: It sounds like you want to write code to work with any kind of REST API whatsoever, but you don't know what all of those APIs do. If that's what your question means, then you're going about it backwards. You can't write an interface to an API which you don't understand. So your approach should be to document how those APIs work and then start writing code to interface with them. I'm making those statements based on what you said :

The problem is that I don't know how to design functions to make rest api calls.  I don't know what all inputs are needed to make api calls besides simple inputs like url, headers, method, body etc. So, I don't know what arguments my api call making functions should have.

To me that sounds like you need to find out those things before trying to write the Universal REST API Caller. Start with one API, then look at another API and see what's different and what you missed, then look at another API and refactor when you find your code is becoming a mess.

I'll clarify what I meant. We can use httpclient, restassured, karate, anyProprietaryFramework etc. to make api calls and get responses. What I am trying to achieve is this :

// You can use this to test any rest service.
class GenericApiCaller {

public static MyResponseObject doGet(MyRequestObject request){
 // 1 - use any library to make api call by using the data in request object.
 // 2 - cast result of 1st step into MyResponseObject response.
 // 3 - return response.
}

public static MyResponseObject doPost(MyRequestObject request){

}

// etc...
}

class MyRequestObject {
// It stores the information needed to make a request to any rest service - url, body, headers etc.
// Rest assured or whichever library you like can pick up those information from this object.
}

I believe that such code could make us 100% independent of the library being used to make api calls.

I agree with Paul; it seems you're going about this backwards. I find it better to take specific examples and look for patterns in them. Once you see a pattern, then you can start generalizing by identifying which parts are variable and which parts are invariable. The invariable parts become your template while the variable parts should be pluggable or configurable or parameterized.

Another thought is that it sounds like you might want to investigate the Adapter Pattern or Bridge Pattern to make the transition from one API to another easier and less disruptive.