REST API – N+1 Problem

N+1 problem is mostly talked in context of ORMs. In this problem, the system needs to load N children of a parent entity where only parent entity was requested for. By default, ORMs are configured with lazy-loading enabled, so 1 query issued for the parent entity causes N more queries i.e. one each for N child entities.

This N+1 problem is often considered a major performance bottleneck and so shall be solved at the design level of application.

N+1 Problem in REST APIs

Though mostly directly associated, yet the N+1 problem is not specific to ORMs only. This can be associated with the context of web APIs as well e.g. REST APIs.

In case of web APIs, N+1 problem is a situation where client applications are required to call the server N+1 times to fetch 1 collection resource + N client resources, mostly because of collection resource not had enough information about child resources to build its user interface completely.

For example, a REST API returning a collection of books as a resource.

<books uri="/books" size="100">
	<book uri="/books/1" id="1">
		<isbn>3434253561</isbn>
	</book>
	<book uri="/books/2" id="2">
		<isbn>3423423534</isbn>
	</book>
	<book uri="/books/3" id="3">
		<isbn>5352342344</isbn>
	</book>
	...
	...
</books>

Here /books resource return list of books with information including only it’s id and isbn. This information is clearly not enough to build a client application UI which will want to typically show the books name in UI rather than ISBN. It may be that they want to show other information such as author and publication year as well.

In above scenario, client application MUST make N more requests for each individual book resource at /books/{id}. So in the total client will end up invoking REST APIs N+1 times.

Above scenario is only for example. Idea is that insufficient information in collection resources may lead to N+1 problem in REST APIs.

How to Solve N+1 Problem

The good thing about the previously discussed problem is that we know what exactly is the issue. And this makes the solution pretty easy. Include more information in individual resources inside collection resource.

You may consult with API consumers, do market research for similar applications and their user interfaces or simply put yourself in the client’s shoe.

Moreover, you may evolve your APIs over the time as your understanding around client requirements improve. This is possible using API versioning.