Skip to main content

4. REST API

  • Date: 2022-12-14
  • Status: Accepted

Context​

The client, used as a web application, requires access to data. We have much data stored in a database. The "wrapper" around the database is a web API that responds to HTTP request. This is a simple and well-known approach.

REST is around for many years now, and other approaches has been developed. GraphQL and gRPC are the other popular ones. Each have their pros and cons.

REST is very straightforward to setup. Many developers are familiar with this technology. The familiarity helps maintains it and requires less learning overhead. The application of REST could be strict and follow some level of maturity.

The downside of REST is that we don't have the ability to fetch several types of data at once. The resource being the main focus, and endpoint usually serves one type of resource. The types are not propagated from the API to its consumers.

That is what GraphQL could do. Also, being a "query", the data that could be fetched from the endpoint is very versatile and maleable. This end up having less HTTP request to retreive all data required by the client.

Decision​

The application is very "resource oriented", meaning that a lot of features are CRUD operations. Examples are that we add an aircraft, we edit it or we could delete it. Same thing with routes, procedures, flight dispatches and so on. The REST is weel suited for this kind of taks with the GET, POST, PUT and DELETE verbs.

Like said before, it's easy to setup and start with it very fast.

Consequences​

The application of REST would not be at a big level of maturity. This is intended because we are focusing on data and the use of it. The client could use some strategies qui avoid recalling the endpoints to refetch the same data when it rerenders.

For the security standpoint, rate limiting is a must. Most clients would not need a massive count of requests.