[FEAT] Spring Rest Docs 도입, Request Dto 세분화

[megymj]

기존에 사용한 Notion API Docs의 문제점

기존에 Notion으로 API 문서를 관리해왔으나, 여러 가지 불편함이 존재한다.

1. HTTP Request, Response에 대한 스펙을 직접 작성해야 한다.
   1. 따라서 코드를 수정해서 결과가 변경되면 매번 Update해야 한다.
2. 100% 정확한 문서라고 단정할 수 없다.
   1. 코드를 수정하면서 변수명이 수정되거나, 변수가 추가되는 등 작업이 수행되면, 그때마다 문서도 수정을 해야 한다.

Swagger API의 문제점

따라서 Swagger를 도입하였으나, Notion API와 비슷한 문제가 발생하였다.

1. HTTP Request, Response에 대한 스펙을 직접 작성해야 한다.
   1. 따라서 코드를 수정해서 결과가 변경되면 매번 Update해야 한다.
2. 프로덕션 코드에 침투적이다.
   1. 이를 방지하기 위해, 따로 Annotation을 만들어서 관리하였으나, 여전히 불편함이 존재하였음.

Spring Rest Docs 도입

• 테스트 코드를 작성해야지 문서가 작성이 되는데, 나는 이미 테스트 코드를 어느정도 작성하였기 때문에 빠른 시간 내에 도입을 할 수 있을 것으로 생각하였음
• 아래 공식문서를 참고한 결과, 초기 세팅이 그렇게 복잡하지 않아 보였다.
  • Spring REST Docs

그 외 리팩토링] Request DTO 세분화

• 현재 Controller로 들어오는 요청 DTO와, Service 계층의 요청 DTO를 동일한 dto 객체를 사용하고 있다.
• 하지만 이 경우 서비스 입장에서는 특정 컨트롤러에 종속된 DTO를 외부로부터 받게 된다.
  • 이에 따라 다른 컨트롤러에서 해당 서비스를 사용할 때 애초에 관심사가 없는 컨트롤러의 스펙에 맞추어서 DTO를 사용해야 한다.
  • 서비스 입장에서는 범용적인 스펙(DTO)를 갖추지 못한다.
• 따라서, controller / service 별로 request DTO를 따로 관리한다.
• Response DTO의 경우 Request와는 다르게 보통 서비스 레이어에서 정의하고, 이를 컨트롤러 레이어에서 받아서 사용하기 때문에 자연스럽게 계층이 분리되어 있는 상황이라고 생각해서, 따로 controller에 추가하지 않았음

수행할 작업

• [x] Spring Rest Docs Configuration
• [x] AuthControllerDocsTest
• [x] FollowControllerDocsTest
• [x] FollowingControllerDocsTest