We have a (I guess) quite common requirement to consume a 3rd party REST-Service.
Particulars:
We only need to read the service (we don’t have to write anything back)
The reading is triggered by a user interaction in the generic UI (button push), and results in standard persisted entities being updated. Persisted if the user presses “save” subsequently.
I was planning to implement this in the client tier. However, a good answer I found in the forum describes implementing this in the middle tier as custom datasource.
Call sequence (In my understanding):
When implemented in middle tier: client tier --> middle tier --> 3rd party service
When implemented in client tier: client tier --> 3rd party service
For our business case, I don’t see the advantages of implementing in the middle tier. Are there advantages?
If implementing on the client tier: Into which jar should the code that consumes the service go? app-gui.jar or app-web.jar?
For our business case, I don’t see the advantages of implementing in the middle tier. Are there advantages?
In my opinion, there are the following points of placing some code at the middle tier:
if it needs fine-grained transaction control or access to databases through JDBC DataSource or JPA EntityManager
if you need it to be accessible from other middleware services or from different clients (web, portal)
if it’s a complex thing being developed by a team and you want to ensure nobody accidentally wires it with some presentation logic
Otherwise it’s completely fine to implement your REST client as a Spring bean in the web module and save your entities using DataManager or by invoking some custom service.
If implementing on the client tier: Into which jar should the code that consumes the service go? app-gui.jar or app-web.jar?
Normally, you have only web module in the project, and it buids to app-web.jar. The gui module is a thing from the past when it was a common part between web and desktop clients.