Who talks to API (REST) ? Web client vs server?

Question

In my app architecture, I have the following components:

• Mobile client
• Api (REST)
• Web client
• Web server (for the web client)

The mobile is talking to the api, that is obvious. However, I was wondering which one of the web components should talk to the api.

At the beginning, I started making it server-side. And then I realized the server is simply calling the api, which the client can do as well - so why not delegate those calls to the client? that is:

1. request: client -> server -> api
2. response: api -> server -> client

we get:

1. request: client -> serevr + client-> api
2. response: server -> client, api -> client.

It has the advantage that our server has to make fewer network calls, hence reduced bandwidth. Now the client may need a bit of increased bandwidth, but it doesn't need to deal with all the users. Also, the client overall loading time isn't increased (I think?), since the client will have to wait for the api response anyway; whether it comes through the server or not.

Hence currently, my web client is talking directly to the web. However, it feels a bit weird, specially regarding authentication.

1. Is that the right choice?
2. Is there a better choice between the two?
3. Are there more advantages or disadvantages for this choice

Answer 1

Configuring your client to operate through an intermediate web server is not a bad setup and probably preferable.

If your web server is just serving static content and piping API requests to the backend then it can probably support the traffic of many API instances. This means you could add capacity by having multiple API instances and have the web server load balance across them.

In addition you can reduce the attack surface of your hosting environment by having the API only accessible on the internal network and route calls through the publicly accessible web server. This way you can also choose how much of the API interface to publish.

And lastly you can handle authentication in one place. If authentication is handled by the web server, and it checks the authentication of each call before routing it to the API server, your API server has one less thing to worry about (this assumes your API server is only accessible on your internal network as above.) You can even implement authentication schemes at this point so that users only have access to a subset of the API server interface.