주의사항

1. 최대한 RESTful 하게 작성해봅시다!
2. API 요청은 전부 /api 로 시작하도록 해주세요
   1. 현재 Server Side Rendering이라서 /api 를 굳이 안붙여도 되지만, 추후 Client Side Rendering으로 변경될 때 확장하기 편하도록 위해서입니다
   2. /api 를 붙이면 ngnix에서 라우팅하기가 편해요
3. 계층형으로 작성하면 좋긴한데 필수는 아니에요
   1. 계층형으로 작성해야 Spring Security에서 경로 설정하기가 편해요
   2. 예를 들어, auth 로 시작하는 경로는 회원이 인증되기 전에 사용하는 경로라서 전부 필터를 패쓰시키도록 설정할 수 있는 느낌

API 명세서는 양이 많아서 굉장히 작성하기 귀찮고, 힘듭니다 ㅜㅜ

• 한번에 다 작성해야겠다고 생각하지말고, 천천히 작성해주셔도 됩니다
• 구현을 하면서 작성해도 됩니다
  • 그런데, MSA시 다른 서비스와 연동해야하는 부분이 많아서 작성이 되어야 서로 논의하기가 편한 부분은 있어요
• 완벽하게 작성하기보다는 초안을 작성한다는 느낌으로 작성하고 추후 스펙에 맞춰 수정해나가면 됩니다!!
  • 완벽하게 꼼꼼하게 하려고 하면 너무 느려지고, 힘들어요

너무 정직하게 쓰지말고 chatGPT 적극 활용해서 작성합시다!!

예시

• 완료 컬럼
  • 해당 API를 구현 완료했다면 완료로 바꿔주시면 됩니다
• 기능 컬럼
  • 해당 API 요청이 어떤 기능에 쓰이는지 적어주시면 됩니다
• HTTP Method 컬럼
  • 해당 API 요청이 어떤 HTTP Method를 쓰는지 적어주시면 됩니다
• API Path
  • API 요청 경로를 작성해주시면 됩니다
• Request Parmeter
  • 이 부분이 작성하기가 힘든데.. 아래에서 설명

Request 예시

Request Header

• 컨트롤러에서 요청을 받을때, 사용되는 헤더
• 헤더에는 여러값이 들어가지만 예를 들어 어떤 사용자가 보낸 요청인지 구분하기 위한 헤더로 X-USER-ID 등이 들어갈 수 있습니다

Request Body

• 컨트롤러에서 요청을 받을때 사용되는 HTTP 바디
• 보통 컨트롤러 Argument에서 @RequestBody, @RequestParam 등으로 받을 수 있는 부분
• 위의 사진과 같은 경우라면 json 요청이 아래와 같이 오게 됩니다

{
	"gender" : "M",
	"birth" : 1992-09-14 (이부분은 불확실 - Local Date 어떻게 오더라?)
	"nickname" : "위대한찌마" 
}

• LocalDate 타입은 불확실하긴한데 대충 이런 느낌

근데 굳이 Type과 required가 필요한가요?

• Controller로 들어오는 요청을 Request 객체로 받아서 매핑할때 검증을 수행하게 되는데, 거기에서 사용하려고 적어둔건데
  • 정 귀찮으면 빼셔도 됩니다

Response 예시

Response Header

• 이 부분이 필요할수도 있긴한데.. 고민중
  • 일단 제외
• 필요할 수 있는 부분은 jwt 생성 완료시 헤더에 담아서 주기 때문입니다

Response Body

• 크게 성공과 실패로 나눴는데..
• 이부분은 다음에 논의해봐야할거같아요
  • 이 부분은 에러코드, 에러 내용 등 Custom Exception을 만드는 부분인데 각 서비스마다 다르게 갈것같아서.. 흠..