Comparing API Architectures: MVC vs REPR (Request, Endpoint, Response)
3 min read

Comparing API Architectures: MVC vs REPR (Request, Endpoint, Response)

Comparing API Architectures: MVC vs REPR (Request, Endpoint, Response)

MVC (Model-View-Controller) and REPR (Request, Endpoint, and Response) are both architectural patterns commonly used in software development. While they share some similarities, there are also key differences that make them suitable for different types of projects.

What is MVC?

MVC is a software design pattern that separates an application into three main components: the model, the view, and the controller. The model represents the data and business logic of the application, the view is responsible for displaying the data to the user, and the controller receives input from the user and interacts with the model to update the view accordingly. This separation of concerns allows for a more modular and scalable design, as well as easier maintenance and testing of the individual components.

What is a REPR?

REPR, on the other hand, is an architectural pattern specifically designed for building APIs (Application Programming Interfaces). An API is a way for different software applications to communicate with each other, allowing them to share data and functionality. In a REPR API, a request is sent from one application to an endpoint on the API, which processes the request and returns a response. This response can be in the form of data, an error message, or some other information.

The Differences

One key difference between MVC and REPR is the scope of their application. MVC is a general-purpose architecture that can be used for a wide range of software applications, including web, desktop, and mobile. REPR, on the other hand, is specifically designed for building APIs, and is not suitable for other types of applications.

Another difference is the way that the two architectures handle data and user input. In MVC, the model is responsible for managing the application data and business logic, while the view and controller handle displaying the data and receiving user input, respectively. In REPR, the endpoint is responsible for processing requests and generating responses, but it does not manage the application data directly. Instead, the endpoint typically interacts with a database or other data storage system to retrieve or update the data as needed.

My Opinion and Experience

In the early days of my development career, MVC was the "biggest and best boy in the streets", almost all web frameworks used its design patterns, so it was always an obvious choice for me. But one problem I've always had in those days with MVC in combination with mid-size teams (5 backend developers, one API product) is code scalability. A lot of the time, the Controllers of our API easily became bloated, the request structure illogical and because of those things, maintainability declines.

So, I tried looking for a solution to decrease my Controller sizes (and I found out that I'm not the only one who does that). One solution I found was one Controller for each endpoint. It didn't seem like a beautiful solution at first, but then I stumbled upon FastEndpoints a .NET Framework that is built upon the REPR design pattern/architecture. And I instantaneously fell in love with it. Each file of code is smaller, and their responsibility is split in a better way.

Example of an Endpoint in FastEndpoint (Request, Endpoint, Response)

Overall, both MVC and REPR are useful architectural patterns that can help developers design and build high-quality software applications. MVC is in my opinion a more general-purpose architecture that is suitable for a wide range of applications, while REPR is specifically designed for building APIs and enables efficient communication between different software applications.