0

I am developing a Spring Boot Application which consumes another REST service to get the User's Account information. The same service provides multiple operations like:

GET: /userid/retrive -to get user and account information

POST: /user/create - to create a new user

POST: /userid/save - to save the user information

DELETE: /userid - to remove the user information from the system

POST: /userid/account : to update account information

...

So All the above apis are exposed by one service. Some of them return the same response object while others do not and each of them have their own request parameters and request headers that should be set before calling.

So what I have done is I have created a Base class which will have the common code and I have extended it for One Rest template per API operation which will set its own request parameters and call the service and also has different exception loggers/messages.

The service also exposes other operations which we start consuming in our upcoming sprints, and I wanted to make sure if we can utilize any existing design pattern for our advantage.

So I am writing this question to know if there are any alternatives or any design patterns you could suggest so as calling the same service would not have multiple rest templates.

0

What you can do is create one interface per resource, which has all the resource's operations:

interface UserResource {
  getUserAccountInformation();

  create(User);

  saveUserInfo(UserInfo)

  remove()

  update(UserInfo)
}

You can then have another interface which is basically represents a client for the other API:

interface SomeClient {
  UserResource user();
}

How you then implement this, is up to you, but no matter the implementation, the calls will always look like this:

client.user().someOp();

You can then refactor the implementation to have a base class, one class per operation, etc. But the refactorings would not have any effect on the users of the client.

When you will be adding additional resources to the client, you will just add the resource to SomeClient interface, in the same way as it is done with the UserResource.

Main point being - if other people will be dependent on your code, they will see a pretty interface and not care how it is implemented. You will then be able to change it however you want and noone will notice unless you break something, which is a the best you can hope for.

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.