REST APIs’ Exhaustion Signs

With REST APIs, it is possible to solve most communication problems between systems on the web. Today, there is hardly an architecture system without a REST API. Often, applications use REST APIs to facilitate conversations between the back end and the front end.

The pattern that APIs bring makes life easier for developers in many ways. However, we should be aware of under-fetching and over-fetching, the key signs of exhaustion that you find in REST APIs.

Architecture

Let’s look at an example architecture to better understand REST APIs’ potential problems. That way, we can get an idea of why over-fetching and under-fetching may arise. In this example, two front-end applications (one mobile and one desktop web) communicate with a back end through a REST API.

In this app, users can send messages and feedback in a very basic architecture. The front-end application makes requests to the API to list users, their messages, and feedback. A request to list a user contains the following data:

Over-Fetching

Based on the example architecture above, let’s assume that the front-end applications must display the following customer data: first name, last name, and age. When making a request to the endpoint (GET https://appendpoint/users/1) to retrieve the desired data, we notice that the REST APIs also fetch and load more unnecessary information. This data has no use on this specific screen. This is an example of over-fetching.

At first, unnecessary data traffic looks unharmful for the architecture. However, in large-scale applications, over-fetching can slow the system performance, causing crashes and errors. One way to avoid over-fetching is to create an endpoint specifically for that screen with only the necessary data. Here’s an example:

However, it is important to note that adding many specific endpoints to a REST API can lead to disorganization, maintenance difficulty, and reduced API maturity levels. The API can get to the point where a new front-end application cannot reuse it and even have multiple endpoints that return similar data, causing confusion.

Under-Fetching

After we get our user’s data, let’s imagine that we must display all that user’s friends and their respective attributes. In the example shown, we have all the endpoints necessary to get this information. However, we will need to make a new request for each friend in the user’s list.

This is an example of under-fetching. The first search brings insufficient data, and we must complete it by making several other requests for different endpoints.

Based on the example architecture, we will need to make four new requests to get all the desired data. Now, suppose we also want to display the user’s feedback, as in the example:

In this scenario, we will need four new requests. This exacerbates our under-fetching problem even further.
To prevent under-fetching, create endpoints where the client resource, for example, brings all the necessary data to the desired screen. That includes all the friends and related feedback in one request. Just keep in mind that with this solution you may also run into problems with over-fetching.

Final Thoughts

Over-fetching and under-fetching are two key signs of exhaustion in REST APIs. Both can cause slowness and possible crashes in applications. That’s why it is important to apply measures to avoid these problems.

Thinking about software for a company’s internal use, with communication only between front-end and back-end, having a REST API with a low maturity level helps avoid breakdowns. However, for more complex architectures, technologies such as OData and GraphQL will be more viable. These reduce or even eliminate exhaustion, ensuring a clean and organized architecture.

If you’re unsure which solution makes the most sense for your organization, contact Programmers today for a consultation. We can facilitate your REST API solution from idea to execution!