소프트웨어 마에스트로에서 "온라인 강의 큐레이션 서비스 - curady"를 개발하며 생긴 일

GET Method

---

GET 요청을 처리할 때, 파라미터를 받는 경우 @RequestParam, @PathVariable등을 사용하여 처리해왔다.

파라미터를 객체로 감싸자

그런데 개발을 하다보니, API를 구현할 때 Request, Response 를 객체로 감싸주는게 좋겠다는 생각이 들었다.

OCP 측면에서 추후에 확장에 유리하다고 생각했다.

예를 들어, 요청 파라미터가 추가되거나 같이 반환해주어야 하는 값이 추가되는 경우,
메서드의 파라미터의 변경이 일어나고, 그에 따라 호출하는 쪽도 싹 다 변경이 일어난다.

하지만 이를 객체로 감싸두면, 객체에서 속성을 추가하고 service단에서 조금만 변경하면 된다.

결론부터 말하자면

 public List<String> getCategories(@PathVariable Long id)

위와 같이 작성하던 코드를

 public MultipleResult<ResponseCategory> getCategories(@ModelAttribute RequestCategory requestCategory)

이런 식으로 변경했다.

이 때, @ModelAttribute를 이용하여 RequestCategory객체 형태로 받는 것으로 작성했는데, 이는 백쪽에서는 코드가 간단해지지만 요청을 보낼 때는 @RequestParam과 다를 것이 없다.
즉, http://localhost:8080?id=1 이런식의 query parameter형식이 된다.

하지만 !!!!!!!!!!!!!

내가 간과한 것은 위와 같이 @PathVariable을 사용하는 경우, 즉 어떤 리소스를 식별하는 경우에는 거의 PK가 사용되고(이건 확실하진 않지만 내 경험상 그랬다.) 그게 아니더라도 @PathVariable을 사용하는 경우는 위처럼 객체로 감싸주는 것에 고려대상(?)이 아닐 수 있다는 것이다.

Path Variable과 Query Parameter에 대해서는 저번에 포스팅 했다.
[Path Variable과 Query Parameter의 적절한 사용]

그렇다보니, 요청을 받을 때 객체로 바로 받는 것은 옳지 않다는 생각이 들었다.

그래서 결론은

Response는 객체로 감싸주되, @PathVariable을 사용하는 경우에는 그대로 던지자.
단 @RequestParam을 사용하는 경우에는 객체로 감싸고 @ModelAttribute를 사용하여, 추후 확장에 대비하자.

최종 코드

@GetMapping("/categories/{parentId}")
public MultipleResult<ResponseCategory> getCategories(@PathVariable Long parentId) {
        List<ResponseCategory> responseCategories = categoryService.getCategoryByParentId(parentId);
        return responseService.getMultipleResult(responseCategories);
    }