Setting up an API skeleton, what should I take into consideration? - Routing, Persistence and Caching

Building an API requires third party libraries, integration with database, cache solutions, testing frameworks, which patterns to use throughout the development between other tasks, that has nothing to do with the business domain. Such step, often, is not take as important as the business application, leading to later consequences.

The goal of this post, is to build a skeleton for apis, as there is not universal programming language, I will focus in the javascript ecosystem. Previously I created a repository that was the first version for this post, the code is a way to start with a PHP based API.

In here, you will find questions and potentially questions for: which libraries to, when to use, and why.


The nature of the web is a HTTP flow in which a client creates a request, the server receives it, process it and sends a response back with the result. Routing is the building block for such flow, as it points to where and how to process it.


Persistence is one of the key factors of any application, in short, applications are as simple as: take an input, transform it, store it. The persistence layer is one of the most important as it has the goal of translate the object model into the desired table (if we are talking about relation databases). On the other hand, with the rise of NoSQL some of the venders took this need of transformation out, which makes “easier” to scale and persist data.

Nevertheless, the choice, be it relational databases or not, the persistence will be there. For such, the ideal library (often called ORM - Object Relational Mapper) should be flexible.


Caching is one of the optional sections for any API, usually the need for such functionality comes from scalability issues.