2

I am working on a design to create a generic rest client for our application for current and future integration's with multiple services (different external systems). Following is a high level diagram

High level design

I am thinking of creating a RestClient per external host, and Store them in a Map with Service name as Key and RestClient as value. Following is my RestClient(will be cached) class that wraps ResteasyWebTarget.

public class RestClient {
    private ResteasyWebTarget target;

    @Singleton
    public class RestClientRepository {
        private final Map<String, RestClient> repository = 
            new ConcurrentHashMap<String, RestClient>() 

My default implementation will be using RestEasy. As my client code will be part of a webapp(multihtreaded environment). I will be using PoolingClientConnectionManager

ClientConnectionManager cm = new PoolingClientConnectionManager();
HttpClient httpClient = new DefaultHttpClient(cm);
ApacheHttpClient4Engine engine = new ApacheHttpClient4Engine(httpClient);
ResteasyClient client = ((ResteasyClientBuilder) ResteasyClientBuilder
  .newBuilder()).httpEngine(engine).build();

Is there a better solution than this approach?

2

In the first place it seems to be right, but I think you want to hide these implementation details. Ask your self: where is the difference between a local database and some remote data servers?

You probably want to have a been for each resource like User and a store like UserStore. Each store has some methods for interaction like:

public User getUser(String, String)
public User getUserById(long)
public void updateUser(User) throws ...
public void deleteUser(User)
public void createUser(User)

This hides the implementation details of your REST API. And the details of caching locally and so on (if you want to cache locally you have to synchronize the data and doing synchronization correctly is very hard to solve!)

  • thanks for your reply.I absolutely agree with your suggestion. That part of design in completely covered. Point of concern is if RestClient per host is a good idea, also Synchronization is not a big worry for me. Would you suggest single RestClient for all hosts?, or the one i am working on. – bornleo Aug 21 '15 at 19:44
  • The RestClient is only for creating WebTargets. So more than one client would be waste of resources, or am I wrong? Is there any argument to have more than one? I would create a map of String -> WebTarget if a WebTarget is cacheable. – Obenland Aug 22 '15 at 7:42
  • Thanks, a good catch. The point for caching the RestClient is that the required filters, and other configurations are implied on this level. The RestClient i am caching has a Webtarget instaance wrapped in it (My apologies i should have posted the code in the first place). I have updated my original post. – bornleo Aug 22 '15 at 11:10
  • Now I think I'm going to know what you want to ask, but one more question: One RestClient is for one WebTarget, and one WebTarget is for one URL, so for one REST resource? Does it make sense to call it RestClient? I would say a RestClient handles many resources or the whole communication between you application and one server. – Obenland Aug 22 '15 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.