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
와 같은 도구를 사용하는 경우 리소스 유형과 요청 및 응답 타입을 쉽게 매핑할 수 있다.
본문의 출처
그 외 레퍼런스
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
/pages/architecturedesignpattern
'Architecture' 카테고리의 다른 글
도메인 엔터티 패턴 (0) | 2023.11.18 |
---|---|
CQRS 패턴이란? CQRS Pattern (0) | 2023.11.09 |