https://chinggin.tistory.com/454
REST API & URI 설계 원칙 (RFC-3986)
REST ( Representational State Transfer : 자원의 상태 전달) - 네트워크 아키텍처이다. 1. Client와 Server가 서로 독립적으로 분리되어 있어야 합니다. 클라이언트와 서버가 한 곳에 구성되어있다던지, 서로의
chinggin.tistory.com
프로젝트 설계 중에 URI 설계가 필요했다.
path 부분은 자원에 대해 서술해야하는 부분으로 어떻게 서술할까 고민을 하던 도중 사내 개발 표준 문서, 현업의 Swagger를 확인해 보니 너무나 헷갈리기 시작했다. 회사에서 내준 과제는 aggregate join을 통해 특정 데이터를 조회하는 것이었다. 아무래도 aggregate join한 데이터를 쓰다보니 path상의 주 리소스가 a, b, c, ... n개의 테이블에서 조인했을 때 나오는 결과여야 하는데 이는 논리테이블의 데이터지 물리테이블의 데이터가 아니라서 새로운 이름의 주 리소스가 필요해 보였다. 하지만 사내 규칙은 SampleController의 Sample이 주 리소스로 들어가고 있었기 때문에 새로운 디렉토리가 필요했다. 애매해서 동기에게 물어보니 aggregate join을 할 때 맨 처음 식별되는 데이터(데이터 관계에서 최상위 데이터 자원)를 다루는 controller를 주 리소스로 path에 넣어야 한다고 했다. 하지만 내규에는 맞지 않아 보여서 이리저리 생각도 해보고 영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의 복습하면서 답을 찾았다.
모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의
실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...
www.inflearn.com
URI 패스상의 리소스는 굳이 물리데이터와 관련되지 않아도 소스파일, 파일 등 식별이 가능한 모든 것이 자원이 될 수 있는 것이었다. 즉 Controller 소스코드 자체도 자원(Resource)이 될 수 있다는 말!
결국 새로운 디렉토리를 생성하여 aggregate join을 하여 얻은 논리데이터를 호출하는 API Controller, Service, Dto를 만들겠다고 설계하였다. 첫 MSA 관련 과제를 받고 진행을 하며 aggregate join의 문제점(AS-IS)을 느끼고 CQRS를 적용한 설계가 왜 필요한 지를 이해하게 해준 과제여서 너무 뜻깊었다.
댓글