REPR 디자인 패턴 개념 / REPR - MVC 비교 / REPR-REST 비교

REPR Design Pattern 이란 ?

REPR 디자인 패턴은 웹 API 엔드포인트를 요청, 엔드포인트, 응답 세 가지로 구성 요소로 정의한다. 자주 사용되는 MVC 패턴을 단순화하여 API 개발에 더 중점을 둔다.

MVC 패턴보다 더 좋을까?

기존 MVC 패턴(Model, View, Controller)은 오랫동안 성공적으로 사용되어 왔지만 API가 아닌 ASP.NET 앱의 경우를 보면 완벽하다고는 할 수 없다. ViewModel과 같이 혼합된 항목들이 존재하기 때문이다. API용 ViewModel을 갖는 것이 API에서 타당할까? 그렇지 않다. 일종의 DTO(Data Transfer Object)라고 할 수 있다.

널리 쓰이는 DTO와 구분하기 위해 이를 ApiModel이라 부르는 사람들도 있다. 하지만 Request와 Response에 대해 서로 다른 타입을 사용하기 위해선 이로는 부족한 경우가 많다. FooDTO나 FooApiModel로만 사용하기에는 이름으로 의도를 명시할 수 없어서 부족하다고 생각된다.

컨트롤러도 마찬가지다. 많은 메서드와 (관련 없는)많은 종속성을 가진 거대한 생성자들로 인해 비대해지는 경향이 있다. 컨트롤러에서 사용하는 유일한 것은 그룹화된 라우팅과 필터뿐이다.

API 엔드포인트를 추가하거나 수정할 때 일반적으로 메서드 하나의 전체 클래스가 아닌 하나의 메서드에만 관심을 갖는다. MediatR과 같은 도구를 사용할 수도 있지만 여전히 목적에는 달성하지 못한 채 구식의 컬트롤러 구조가 사용되곤 한다.

더 나은 접근 방식은 다중 작업 컨트롤러를 완전히 없애고 API 엔드포인트를 수용하는 것이다.

REPR 패턴의 이점

PEPR Design Pattern을 적용하게 되면 API들을 개별 엔드포인트 클래스 중심으로 설계할 수 있다. 단일 컨트롤러 작업처럼 단일 Handle메서드가 있다. 각 엔드포인트는 선택적 요청 유형과 선택적 응답 유형을 정의할 수 있다.

Request-Endpoint-Response 또는 PEPR이라 불리는 이 패턴은 MVC보다 API 엔드포인트를 개발하기 위한 훨씬 간단한 패턴이다. View가 없다. 불필요하게 확장된 컨트롤러 또한 없다. 이 방식의 유일한 관심사는 요청과 응답뿐이다.

REST 패턴과 다를까?

REPR 패턴과 REST 패턴은 다르다.
REPR 패턴은 API 엔드포인트를 정의하는 패턴이며 리소스 기반의 패턴이 아니다. RESTful 리소스를 정의할 수 있지만 RPC 방식의 엔드포인트 또한 정의할 수 있다.

REST 방식 리소스와 함께 REPR을 사용하려면 요청 및 응답 유형 내에 적절한 리소스의 스키마를 포함하기만 하면 된다.

예를 들어 Customer 리소스가 있는 경우 GetCustomerRequest와 GetCustomerReponse 타입을 지정하면 된다.
요청 타입은 Client가 생성한 CustomerId 속성을 포함할 수 있고,
응답 타입에는 새로 생성된 Customer 리소스가 속성으로 포함된다.
AutoMapper와 같은 도구를 사용하는 경우 리소스 유형과 요청 및 응답 타입을 쉽게 매핑할 수 있다.

본문의 출처

DevIQ - REPR Design Pattern

그 외 레퍼런스

The .NET Docs Show - Controllers are Dinosaurs: The Case for API Endpoints

MVC Controllers are Dinosaurs - Embrace API Endpoints

Ardalis.ApiEndpoints NuGet Package

Ardalis.ApiEndpoints GitHub repo

FastEndpoints Docs

FastEndpoints NuGet

 

/pages/architecturedesignpattern