도메인 모델의 요약 및 세부 정보를 참조 할 때 Restfull API 디자인 패턴

Question

간단한 응용 프로그램의 경우 사용자 정보를 관리하는 2 개의 restfull apis가 있습니다.

예를 들어, api A는 /users으로 정의되며 사용자 목록을 반환합니다. api B는 /user/{id}으로 정의되며 사용자 ID로 식별 된 사용자를 반환합니다.

그러나 api A를 사용하는 첫 페이지는 이름, 나이, 성별 등과 같이 사용자의 몇 가지 속성 만 필요로하는 사용자의 테이블을 표시하는 요약 페이지입니다. 사용자의 세부 정보 정보에는 사회 보장 번호, 은행 계좌와 같은 더 많은 속성이 필요하며 속성은 데이터베이스에 저장되지 않지만 다른 시스템에는 저장됩니다. 그래서

, 나는/userSummaries 및 /userDetailes/{ID}처럼,이 두 가지 시나리오에 대해 서로 다른 API를 사용하여 바로 이해할 수있을 것이다 내가?

어떤 조언을 위에서 언급 한 API를 사용한다.

Answer 1

예, 두 API를 분리했습니다. API 레이어에는 응답을위한 다양한 모델이 있습니다 (예 : UserSummaryModel, UserProfileModel). 이 모델은 뷰 모델 또는 DTO (데이터 전송 객체)로 작동합니다. getter와 setter 만 포함하는 빈혈 클래스입니다. 별도의 프로젝트에있는 리치 도메인에는 사용자 (및 기타 도메인 모델) 비즈니스 로직, 제약 조건, 유효성 검사 등이 포함됩니다.

따라서 API 레이어에서보기 모델을 도메인 모델에 매핑해야합니다. 수동으로 맵핑을 수행하거나 Automapper를 사용할 수 있습니다.

Answer 2

bounded context마다 api가 있어야합니다.

그렇다면 필자는 쓰기 및 읽기 모델을 API 끝점에 매핑해야합니다. Aggregates commands은 엔드 포인트의 put/post/patch/delete에 맵핑되어야합니다. Read-models 쿼리는 get api 끝점과 일치해야합니다.

UPDATE : 그래서

, 나는 /userSummaries 및/userDetailes/{ID} 내가

위 을 언급 단지 사용하는 API처럼,이 두 가지 시나리오가 서로 다른 API를 사용한다

예. 각 읽기 모델에 대해 API 끝점을 가져야합니다.

는 https://vimeo.com/41763224 및 https://yow.eventer.com/events/1004/talks/1047

Answer 3

@Constantin GALBENU는 각 상황에 대한 API를해야 옳은 일을 참조하지만 당신은이 상황에서 데이터를 가져 오기 위해 API를해야 할 경우가있을 수 있기 때문에이 또한 응용 프로그램에 따라 다릅니다.

난 그냥 당신이 당신의 API의 도메인과 응용 프로그램의 도메인을 혼동해서는 안된다는 것을 추가하고 싶습니다. I.E. 표준적인 BoundedContext에 후킹 할 수있는 일반 API를 가질 수 있으며 구체적인 구성이나 자동화 된 방법을 통해 기능을 공개 할 수 있습니다. 그러나 이것은 API가 요청/로깅/응답에만 관심이 있으므로 API 코드가 귀하의 앱 도메인의 일부라는 것을 의미하지는 않습니다. - API와 관련된 모든 것.