입사 후 공부하며 기술 스텍을 쌓던 내게 던져진 첫 실무 과제.
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 구현
등을 계획중이다.
그럼 이만 !! ✋