[Spring Boot]2. REST API, 넌 누구냐.
메뉴판과 같은 당신, API
REST API를 언급하기에 앞서, API란 무엇일까?
필자가 컴퓨터 과학을 처음 접할 때, 가장 많이 의문이 들었던 점이다.
"명세서 API 사용해야하지 않나 ..?" "그거 API 사용하면 해결되잖아" 등 가장 많이 들었던 단어이기도 하고 처음 공부할 시기에 많이 들었던 단어라서 많이 궁금했었다.
프로그래밍은 내가 처음부터 무언가를 만드는 것이 아니라, 다른 사람들이 이미 만들어놓은 기능을 잘 활용하는 것에 더 가깝다.
집을 짓기 위해서 망치와 드릴 등과 같은 공구들을 직접 만드는 것이 아닌 시중에 판매되고 있는 공구를 구매하여 잘 활용하는 것처럼 말이다.
API를 간단하게 설명하자면, 일종의 '메뉴판'이라고 생각하면 될 것 같다.
손님과 직원 사이에 무언가 연결 다리가 있어야지만 어떤 음식이 있는 지를 알고 구매를 할 수 있듯이 '내가 만든 음식은 이건데 너한테 필요해?'라고 직원이 말하면, 손님은 '내가 원하던 음식이 있으니 이걸로 줘'라고 말하는 셈이다.
즉, API는 개발자가 작성한 사양 및 인터페이스를 의미한다.
REST는 무엇일까?
우선 REST의 약자부터 살펴보자.
Representational State Transfer의 약자로 한 단어씩 끊어서 해석해보면, '표현되는' '상태' '전송'이라고 알 수가 있다.
말 그대로 현재 나타내는 상태를 전달한다 ! 라는 것인데, 중요한 것은 '현재 상태'이다.
A와 B가 서로 통신한다고 생각해보자.
REST와 같이 통신 간의 서로 현재 상태를 전송한다고 했을 때, 생존가능성과 회복탄력성을 매우 향상시킬 것이다.
왜냐하면 통신 문제나 오류가 발생하는 최악의 상태에서 B가 오류가 발생했다고 해도 A가 B의 '현재 상태'를 알고 있기 때문에 회복할 수 있기 때문이다.
그렇기 때문에 A의 재요청으로 A와 B는 중단된 곳에서부터 다시 통신을 이어갈 수 있다.
아직 끝나지 않았다. 스프링 MVC와 RestController
스프링 부트를 사용하는 이유는 반복되는 작업을 줄여주기 때문에 간단하게 만든다는 것이었다.
그중에서 MVC(Model, View, Controller)에 대해서 알아보자.
스프링 MVC는 화면이 서버 렌더링된 웹페이지로 제공된다는 가정하에, 데이터와 데이터를 전송하는 부분과 데이터를 표현하는 부분을 분리해 생성한다.
Model : data나 business logic을 나타내며, data의 변화에 따라서 logic을 처리한다.
View : 주로 UI를 나타나며, 사용자의 입력값을 Controller에게 전달한다.
Controller : 사용자의 입력으로부터 Model, View를 변경한다.
이 세 가지를 통해서 어플리케이션이 관리되는데, Controller는 '@Controller' 어노테이션을 통해 사용한다.
@Controller가 붙은 클래스는 Model 객체를 받는다.
@Controller 뿐만 아니라 @ResponseBody를 클래스나 메서드에 추가하여 JSON, XML 형식처럼 형식화된 응답을 반환하도록 Controller 클래스에 지시할 수도 있다.
해당 두 가지의 어노테이션을 같이 사용하면 장점이 많기 때문에 각각을 입력하는 번거로움을 줄이고자 '@RestController'가 탄생하였다.
REST API는 해당 어노테이션을 기반으로 만들 수 있다.
REST API = REST + API
이제 본격적으로 REST API에 대해서 살펴보자.
HTTP의 메서드인 POST(생성), GET(읽기), PUT(업데이트), PATCH(업데이트), DELETE(삭제)를 기반으로 한다.
각각의 매서드는 @RestController 어노테이션이 붙은 클래스에서 실행된다.
여기서 지켜봐야할 점은 바로 어노테이션 역시 반복되는 점을 생략한다는 것이다.
이후에 나오는 코드를 자세하게 보고 싶다면 github를 참고해주세요.
GET
GET을 할 때는 @RequestMapping(value = "/클래스명", method = RequestMethod.GET)을 통해 전체 클래스를 읽는다.
하지만 method = RequestMethod.GET를 계속해서 반복하는 것이 불편하기 때문에 @GetMapping("/클래스명")을 통해 반복을 줄일 수 있다.
특정 객체만 읽고 싶은 경우에는 @GetMapping("/클래스명/{이름}") 형태의 어노테이션을 사용한다.
다시 말해, RequestMapping 어노테이션 안에 GetMapping 어노테이션이 포함되어 있다는 것이다.
(이 외에도, @PostMapping, @PutMapping, @PatchMapping, @DeleteMapping 등이 있다.)
POST
POST를 할 때는 @RequestBody를 통해 원하는 객체의 바디 부분을 추가할 수 있다.
PUT
PUT을 할 때는 @PathVariable을 통해 특정 식별자를 검색하고 POST에서의 @RequestBody를 통해 값을 업데이트한다.
만약 해당 식별자가 없다면 새로운 값을 다시 생성하여 추가한다.
PUT 메소드의 가장 큰 특징은 나머지 셋과 달리, 상태 코드가 필수라는 점이다.
상태 코드는 앞서 REST처럼 현재 상태를 전달하는 것을 의미한다.
ResponseEntity를 반환하는데, 특정 식별자가 있다면 200을 반환하고 그렇지 않다면 201을 반환하여 새로 생성한다.
DELETE
DELETE를 할 때는 @PathVariable을 통해 특정 식별자를 받아서 목록에서 제거한다.