Best way to consume REST service within Servlet on same server?

Question

I'm builiding a web app and I'm implementing a RESTful API to expose the server to all sort of clients.

On the web client I want to have both server rendering and client rendering. The majority of the layout will be server rendering and changes/updates will be through javascript.

In order to serve the HTML from the server I need to consume the REST API, so I was thinking on putting the logic on servlets which will interact with the REST API and then print the result using JSP.

What I would like to know is:

• What is the best way to do consume the REST services in the servlets? I mean they are on the same server so should I still implement a REST client on the servlets?
• Won't that create too many http requests? Client -> Servlet -> REST API, isn't there a way to do it in a more direct way?

Answer 1

You have 2 options :

• Consuming the REST API using AJAX requests. In this case, your web client will return to the web browser a "static" page, that will retrieve all the needed data using AJAX requests to the REST API. Using this approach, you will transport the main processing in the client side (client meaning the web browser of end users). For an easier implementation of AJAX requests and related concepts, such as client-side validation and transformation of data, you can leverage various JS frameworks (such as jQuery, Angular JS etc).

Disadvantages: processing load in client instead of server might degrade application's performance, security issues in client in case of bad design

---

• Consuming the REST API using back-end requests. In this case, you will make the necessary data loading using the REST API from back-end calls. After you have loaded necessary data and dynamically generated the whole page, you will return it to the web browser. In this case, the Javascript used will be minimal and only used for animations (and not data loading). There are various libraries-frameworks that will make your job easier for creating the API calls and consuming the responses. Some of them are JAX-RS client, Unirest, Resty

---

In order to avoid the architectural pattern Client -> Servlet -> REST API, you could design your application in such a way, that the service is returning various forms of responses (JSON-REST, HTML etc.). In this way, after loading the data, depending on the type of the client, you could choose the format of the response and use the suitable service.

Answer 2

What I usually see is a simple abstraction where Service classes return the data needed in Object form and Rest controller classes render to JSON or whatever you are marshalling to. This would allow you to just reuse the Services for your server side needs and not call back into yourself.

Answer 3

Calling your RESTful services will result in more HTTP connections (and also threads) open on your server. If you are not careful and manage the HTTP client correctly you could leak connections. If the service interface changes, how will you know? Will you remember to update your servlets? Developers would expect the compiler to give some errors. All of this would mean both a performance and maintenance overhead.

What you want to do is separate the contract (RESTful invocation and representation) from the service logic see SOA Service Pattern. This allows you to create many kinds of client representations (rest, static web/jsp, soap, Ejb/rmi, etc) while reusing the same logic throughout.