JPA 사용한 카테고리 구현 (infinite depth) - 05 API Controller 구현

Joshua_Kim·2021년 7월 31일
1
post-thumbnail
post-custom-banner

"민재씨 무한뎁스로 카테고리 로직 구현해봐요"

입사 후 공부하며 기술 스텍을 쌓던 내게 던져진 첫 실무 과제.

stack : Springboot 2.3.6 RELEASE, gradle, JPA, mysql ...


👉🏻 JPA 사용한 카테 고리 구현 1편 (요구조건, Entity, Repository) (링크 click)

👉🏻 JPA 사용한 카테 고리 구현 2편 (DTO, Service - save) (링크 click)

👉🏻 JPA 사용한 카테 고리 구현 3편 (Service - update, delete, get) (링크 click)

👉🏻 JPA 사용한 카테 고리 구현 4편 (Service - TDD, Test 코드 만들기) (링크 click)

이번 포스팅에서는 API Controller 에 대해 다뤄 보겠다.
RESTful에 대한 개념도 잠시 언급하고자 하는데, RESTful에 대한 자세한 글은 따로 포스팅 할 예정이다.

🌱 Controller의 기능은 뭐야?

👉🏻 Controller 의 기능

  • Springannotation이 전부다. 사실 아니다
    많은 동작 원리들과 Spring의 매커니즘이 annotation을 기준으로 돌아간다.

  • 처음 Spring을 접하거나, 공부를 시작하게 되면 Spring MVC 모델을 통해 Application 구조를 짜게 되고, project를 진행하게 된다.

  • MVC의 의미는 Model, View, Controller 인데, 여기서 Controller가 오늘 포스팅의 주제다.

  • ControllerRestController의 차이도 중요한데, 우선 오늘 포스팅에서는 생략하고, 따로 Spring MVC에 대한 포스팅이나 Controller에 대한 포스팅에서 더 자세히 설명하겠다.

  • 우선은 매우 간단하게 Controller는 사용자의 요청을 받아 View로 보내주는 역할을 한다.

  • view로 보내지 않고 데이터를 보내고 싶을 때는 메소드 위에 @ResponseBody 어노테이션을 써주면 된다.

  • 만약, 해당 Controller의 모든 메소드가 데이터만 전달한다면 @Controller 가 아닌, @RestController 어노테이션을 사용하면 @ResponseBody를 사용할 필요가 없다.

  • 개발자는 코드로 이야기한다, 코드로 확인해보자


⚙️ API Controllers

👉🏻 saveCategory

  • Category를 저장하는 메소드이므로 http protocol methodpost
@Controller
@RequiredArgsConstructor
public class CategoryApiController {
    private final CategoryService categoryService;
    @PostMapping ("/categories")
    @ResponseBody
    public Long saveCategory (CategoryDTO categoryDTO) {
        return categoryService.saveCategory(categoryDTO);
    }
  • @RequiredArgsContstructor를 통해 private final로 선언한 CategoryService 인스턴스를 주입받는다. DI는 생성자주입, setter를 활용한 주입 등이 있는데, 최근에는 이 어노테이션을 통해 의존성 주입을 받는 것이 트렌드다.

  • 위에서 언급했듯이 Post방식이므로, @PostMapping을 통해 사용자의 요청을 받는다.

  • 요청 url/categories다.
    요청 url의 네이밍을 RESTful하게 지어야하는데, RESTful관련해서는 따로 포스팅하도록 하겠다.

  • @ResponseBody를 통해 해당 메소드의 리턴값이 view로 가는것이아니라, 데이터 전달임을 명확히하자.

👉🏻 getCategoryByBranch

  • Category를 불러오는 메소드이므로 http protocol methodget
 @GetMapping ("/categories/{branch}")
    @ResponseBody
    public CategoryReturnDto getCategoryByBranch (@PathVariable String branch) {
        return categoryService.getCategoryByBranch(branch);
    }
  • 해당 카테고리를 불러올 때, branch를 검색하여 모든 카테고리를 조회할 수 있도록 요구 스펙을 따랐다.

👉🏻 updateCategory

  • Category를 업데이트하는 메소드이므로 http protocol methodupdate

  • 사실, update기능에 대한 http protocol methodpatch라고 하나 더 있다.
    기능의 차이는 거의 없다고 봐도되지만, 개념적으로 update는 모든 값을 바꿀 때, patch는 일부만 수정할 때로 개념적으로 나뉘어 있다.

@PutMapping ("/categories/{branch}/{code}")
    @ResponseBody
    public Long updateCategory (@PathVariable (name = "branch") @NotBlank String branch,
                                @PathVariable (name = "code") @NotBlank String code,
                                CategoryDTO categoryDTO) {
        return categoryService.updateCategory(branch, code,categoryDTO);
    }
  • 같은 branch에 같은 code값을 가진 category객체는 없게 설계했다.

  • 사실, 유일값인 id를 받아와서 수정하게 하도록 하는 것이 가장 간편하지만, 사용자 입장에서 pk를 아는 것이 어렵고, 요구 스펙에도 branchcode로 변경할 category를 찾을 수 있게 해달라고 해서 이렇게 설계했다.

👉🏻 deleteCategory

  • Category를 삭제하는 메소드이므로 http protocol methoddelete
@DeleteMapping ("/categories/{branch}/{code}")
    @ResponseBody
    public void deleteCategory (@PathVariable (name = "branch") @NotBlank String branch,
                                @PathVariable (name = "code") @NotBlank String code) {
        categoryService.deleteCategory(branch, code);
    }
  • update와 마찬가지로, branchcode로 찾아와서 해당 category를 삭제한다.

🙏🏻 'JPA 사용한 카테고리 구현' 시리즈를 마치며

  • 개발log 시리즈를 끝냈다. 우아아아

  • 이번에 들어간 회사에서 처음으로 JPA를 접하고, 배우면서 참 편하다 생각을 많이 했다. 익숙해 지기 위해 JPA를 활용하여 알고리즘 로직을 짜게 되었고, 이번 시리즈에서 만든 카테고리 로직이 실제 우리 회사 개발 서버에 AWS를 통해 Deploy되었다. (물론 실제 로직은 블로그에 포스팅한 로직들보다 좀더 복잡하다.)

  • velog를 통해 실무에서 만든 것들을 다시 정리하고, 설명하면서 개인적으로도 많은 공부가 되었다.

  • 앞으로의 포스팅 계획은 RESTful API, POSTMAN 사용법, 카카오톡 알림톡 API 구현등을 계획중이다.

  • 그럼 이만 !! ✋

profile
인문학 하는 개발자 💻
post-custom-banner

0개의 댓글