
입사 후 공부하며 기술 스텍을 쌓던 내게 던져진 첫 실무 과제.
stack : Springboot 2.3.6 RELEASE, gradle, JPA, mysql ...
이번 포스팅에서는 API Controller 에 대해 다뤄 보겠다.
RESTful에 대한 개념도 잠시 언급하고자 하는데, RESTful에 대한 자세한 글은 따로 포스팅 할 예정이다.
Spring은 annotation이 전부다. 사실 아니다
많은 동작 원리들과 Spring의 매커니즘이 annotation을 기준으로 돌아간다.
처음 Spring을 접하거나, 공부를 시작하게 되면 Spring MVC 모델을 통해 Application 구조를 짜게 되고, project를 진행하게 된다.
MVC의 의미는 Model, View, Controller 인데, 여기서 Controller가 오늘 포스팅의 주제다.
Controller와 RestController의 차이도 중요한데, 우선 오늘 포스팅에서는 생략하고, 따로 Spring MVC에 대한 포스팅이나 Controller에 대한 포스팅에서 더 자세히 설명하겠다.
우선은 매우 간단하게 Controller는 사용자의 요청을 받아 View로 보내주는 역할을 한다.
view로 보내지 않고 데이터를 보내고 싶을 때는 메소드 위에 @ResponseBody 어노테이션을 써주면 된다.
만약, 해당 Controller의 모든 메소드가 데이터만 전달한다면 @Controller 가 아닌, @RestController 어노테이션을 사용하면 @ResponseBody를 사용할 필요가 없다.
개발자는 코드로 이야기한다, 코드로 확인해보자
Category를 저장하는 메소드이므로 http protocol method는 post다@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로 가는것이아니라, 데이터 전달임을 명확히하자.
Category를 불러오는 메소드이므로 http protocol method는 get다@GetMapping ("/categories/{branch}") @ResponseBody public CategoryReturnDto getCategoryByBranch (@PathVariable String branch) { return categoryService.getCategoryByBranch(branch); }
branch를 검색하여 모든 카테고리를 조회할 수 있도록 요구 스펙을 따랐다.Category를 업데이트하는 메소드이므로 http protocol method는 update다
사실, update기능에 대한 http protocol method는 patch라고 하나 더 있다.
기능의 차이는 거의 없다고 봐도되지만, 개념적으로 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를 아는 것이 어렵고, 요구 스펙에도 branch와 code로 변경할 category를 찾을 수 있게 해달라고 해서 이렇게 설계했다.
Category를 삭제하는 메소드이므로 http protocol method는 delete다@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와 마찬가지로, branch와 code로 찾아와서 해당 category를 삭제한다. 첫 개발log 시리즈를 끝냈다. 우아아아
이번에 들어간 회사에서 처음으로 JPA를 접하고, 배우면서 참 편하다 생각을 많이 했다. 익숙해 지기 위해 JPA를 활용하여 알고리즘 로직을 짜게 되었고, 이번 시리즈에서 만든 카테고리 로직이 실제 우리 회사 개발 서버에 AWS를 통해 Deploy되었다. (물론 실제 로직은 블로그에 포스팅한 로직들보다 좀더 복잡하다.)
velog를 통해 실무에서 만든 것들을 다시 정리하고, 설명하면서 개인적으로도 많은 공부가 되었다.
앞으로의 포스팅 계획은 RESTful API, POSTMAN 사용법, 카카오톡 알림톡 API 구현등을 계획중이다.
그럼 이만 !! ✋