How should clients interact with services?

Question

I have a client web application. The user clicks buttons, gives inputs, makes selections, etc... This is all done with Java using the Spring framework.

The client talks to another service that I have built in Java (with Vertx). This service talks to the database, handles caching, and the endpoints return values.

user navigates to web page--->client controller handles request mapping--->
--->request mapping uses controller method to return view--->
--->view's JS makes requests to service--->service returns model data

Now, I like the idea of control that Spring controllers offer. My client's pages use the Spring controllers to return views, and a small amount of model data.

However, what I am doing to call my service is: in my view's JS, I am making AJAX calls directly to the service. I mean, it works, and that is what was suggested for me to do, but I'm not sure if that is what I should be doing.

The alternative would be for my client to make JS calls to the client app's controller, and let the controller from my client app make requests to and receive responses from my service, then pass those responses back to my JS. I feel like this is probably the "cleaner" or "better" way to do this, but I am only about a year into programming with Java and don't know what the best way of doing this is. Essentially,

user navigates to web page--->client controller handles request mapping--->
--->request mapping uses controller method to return view--->client view's
JS makes requests to client controller--->client controller makes request
to service--->service returns data to client controller--->
client controller handles data and returns data to client view's JS

My gripes are that the JS exposes more than I would like it to in terms of the service's endpoints. Furthermore, I feel like using my client's controller to call the endpoints just seems... right.

I'd prefer input of experienced developers on what is right and/or wrong about these design patterns.

Answer 1

I've seen it successfully implemented both ways. Using a client controller is a fairly easy way of narrowing the exposed surface of the API (provided you lock-down access to the back-end services, otherwise you're just wasting your time). This method also allows you to turn the Client Controller into an adaptor to adapt the return values from the API into something more UI-centric (eg map codified values into text via an i18n file) and pare down any surplus data before it goes to the client.

However, there's an element of extra work or duplication as well as a performance overhead (hops, marshalling and unmarshalling).

If you ever suspect you're going to expose the underlying API or the client's usage of it is going to grow to the point where you've effectively created a shadow copy of your API, you should just put in place a robust Auth and Auth system to only allow calls from the appropriate places. This is not a trivial task, but would allow you to expose the API to other consumers.

The current and expected future usage of your API (but don't go all YAGNI on this!) should shape your decision. It may be appropriate to have the Client Controller layer doing filtering and shaping to avoid excessive client payload or not if you want the client to have a more transparent representation of your resources.