[Refactor]기능에 대해 Mapping과 URL을 통한 정리

개요

프로젝트를 진행하면서 기존에는 @PostMapping과 @GetMapping에 대해서만 사용을 했었다.

그러다보니 대부분의 Mapping을 셋팅 할 때 URL을 남겨줘야 하는 문제가 있었고, /만 선언을 하는경우는 거의 없었다.

이후, 회원정보의 수정기능에 대해서 제작을 하면서 다음과 같이 Controller영역에 대해서 개발을 진행했었다

//기존의 소스
@PostMapping("/user/update")
public ResponseDto userUpdate(@Valid @RequestBody UserInfoUpdateDto userInfoUpdateDto) {
    return userInfoService.updateUserInfo(userInfoUpdateDto);
  }

다음과 같이 Mapping을 셋팅했었고, 다음과 같은 리뷰를 받게되었다.

해당 리뷰를 받은 이후, Mapping의 종류에 대해서, URL을 작성하는 전략에 대해서 생각을 해보게 되었다.

---

Mapping전략

기본적으로 내 프로젝트는 간단한 CRUD가 들어가는 경우가 많았다.
그러다보니 간단하게 기능을 분류하기가 쉬운편이었고, Mapping에서도 그걸 표현하기 쉽게 구분된 Mapping이 있는걸 알게 되었다.

 

일단 크게 4가지의 Mapping만을 사용하기로 마음을 먹었고, @GetMapping, @PostMapping, @PutMapping, @DeleteMapping을 사용하고자 하였다.

 

1. @GetMapping : 데이터의 조회가 주 기능인 경우
2. @PostMapping : 데이터를 삽입이 주 기능인 경우
3. @PutMapping : 데이터의 수정이 주 기능인 경우
4. @DeleteMapping : 데이터의 삭제가 주 기능인 경우
5.  

크게 4가지로 분류를 하였으며, DeleteMapping의 경우 실제로는 Data를 삭제하지 않는 경우도 있지만 그럼에도 Delete를 사용하였다.

그럼에도 Delete를 사용한 이유는
URL과의 매칭을 봤을 때 수정이라고 하면 이게 정보수정인지? 삭제기능이 주된건지? 혼돈이 올 수 있다는 생각을 하였다.
그렇기 떄문에 실제로는 데이터를 수정한다 해도, 목적이 삭제처럼 되는 경우기 떄문에 Delete를 사용하였다.

 

 

Ps. @PutMapping은 멱등성이 있고~하는 문제는 일단 우선순위는 아니었다.. 추후 해당 부분에 대해서는 추가적으로 공부를 하고자 한다.

---

URL전략?

경로의 경우에는 대부분 /를 줬다, 예외로 조회를 하는 경우 /list등의 추가적인 표시를 해주는 정도로 표현을 하기 시작했다.
나는 / 한개의 경로만 사용했지만, 해당 경로로 4개의 기능을 분류할 수 있는 용이함이 생겨서 명칭을 정하는데 많이 편해지게 되었다.

---

변경이후 코드는?

Mapping과 URL을 분류하는 작업을 하게된 계기의 소스코드와는 다른 코드지만 아래의 이미지와 같은 방식으로 URL을 변경 할 수있게 되었다.

기존이었으면 등록이나 수정이나 삭제 전부 @PostMapping을 사용한 이후 /update나 /insert혹은 /add등의 문구를 적었을 테지만, 이후에는 대부분 루트경로만 사용하게 되었다.

 

혹시 URL의 명칭을 짓는데 고민이 있는 사람이라면 Mapping으로 분류해보는 건 어떨가 싶다.