REPR The Best design pattern for Implement WebApi

I have been programming in API for a very long time and I also help companies to move out of their technical debt. I like to design and oragnize API’s in a way that it is easy to maintain and scale. But I can tell you that the traditional way of organizing API’s in Controllers are always a source of pain in ASP.NET projects.

ASP.NET WEB API Controllers are essentially an anti pattern. They are always fat and huge. They are collection of methods that never call one another and do not operate on same state. They are not cohesive. They tend to get bloated over the time of development. But since that is the approach which comes with the default tempate, most of the developers started to follow it.

Ofcourse you can use tools like MediatR to solve this problem. But what if I tell you that you can do it without any third party library or extra plumbing ?. Let's learn how to overcome this using REPR Pattern.

Repr Pattern

Why REPR Pattern ?

Well the answer is simple. API Endpoints are really just controllers with few constraints applied to them. They literally inherit from ControllerBase and so, its acceptable to do this way, and everything that works with Controllers, like routing, model binding, model validation, dependency injection, filters, etc. all works just fine with API Endpoints because, you might have guessed it, they're again controllers.

Yes its going to be controllers again but with Single Responsibility Principle applied to them. They are going to be small and cohesive. They are going to be easy to maintain and scale. They are going to be easy to test. They don't change often like how we add new ActionMethod to Controllers. Lesser the change in file, lesser the chances of breaking things and introducing bugs.

What is REPR Pattern ?

The REPR Design Pattern defines web API endpoints as having three components:

1. Request — The shape of the data the endpoint expects
2. Endpoint — Logic the endpoint performs given a request
3. Response — The shape of the data the endpoint returns

Providing a simplified concepts to enable the development REST API endpoints and enforcing the Single Responsibility Principle for endpoints. The only Models that the Developers need to care about are the Request and Response.

Not all endpoints will require data for their Request or Response, in some cases taking in no inputs or returning just an HTTP status code. But an empty request or response is still a valid one in this pattern.

Pros & Cons of REPR (Request Endpoint Response)

Like any other design patterns REPR has also various plus & minus points. While developers are choosing REPR as design pattern in their project, the points below should be considered.

Pros

• Separation of Concern: The REPR pattern is for a clear separation of concerns by dividing the functionality of applications into different separate components. As an advantage code becomes cleaner and more maintainable.
• Code Reusability: The pattern allows for better code reusability by separating the request handling and response generation logic into different reusable components. This brings modular and reusable code, reducing duplication and improving development efficiency.
• Better Performance: The REPR pattern promotes efficient memory utilization through customized request handling and response generation.
• Consistency: By following REPR pattern, developers can ensure higher code consistency than old MVC Controller approach.
• Better Error Handling: The pattern allows better error handling by defining specific responses (data & HTTP status codes) for exceptions for each endpoint. This can be achieved globally as well as individual API level.
• Testability: REPR pattern ensures unit testing components to be handled in more efficient way by separating request/response handling. It enhances the test coverage and helps to troubleshoot fast.
• Scalability: REPR decouples the request & response processing logic, which helps to make more scalable applications in terms of individual components as needed. This results in better performance & resource management.
• Improve Security: Again, by separating the request & response logic, REPR pattern helps to improve better access & authorization controls.
• Easy Debugging: For a complex application with huge numbers of multiple endpoints & requests, REPR pattern helps to debug through the application easily by identifying which component is causing issues.

Cons

• More number of files to manage: Every APIs are. Being managed in a separate file unlike a Controller.cs file. This leads to a massive number of files under the Controller folder. Developers must manage with proper folder & indent structure to maintain the APIs.
• Duplicating Attributes: Developers might feel sometimes that they are duplicating some of the attributes on the APIs.
• Separate APIs in Swagger by default: While developers are creating separate files for every API, Swagger reads through all and shows all APIs separately. For e.g. if we have Two APIs like api/product/add and api/product/getall, these two wouldn’t be under Customer module initially. Developers need to tag those together to show them as a single module.

Future Plan

In the next Articles I will implement this pattern with CQRS + Mediator + Minimal Api and use Carter or fast-Endpoint library for set routes.

Please follow me in Medium.

Tohid haghighi - Medium