REST API (2) Event 생성 API 구현
오늘의 목표 : TDD 기반으로 Event 생성 API 구현(MockMvc 사용)
오늘의 목차 :
1. 입력값 전달 후 201 JSON 응답받기
2. EventRepository 구현 후 id는 DB에 들어갈 때 자동생성된 값으로 나오는지 확인
사전지식
MockMvc (스프링 MVC 테스트 핵심 클래스)
웹 서버를 띄우지 않고도 스프링 MVC (DispatcherServlet)가 요청을 처리하는 과정을 확인할 수 있기 때문에 컨트롤러 테스트용으로 자주 쓰인다.
1. 입력값 전달 후 201 JSON 응답받기
contentType 및 accept는 HTTP 요청 및 응답의 헤더에 관련된 사항 으로
contentType 헤더는 클라이언트가 보내는 요청의 본문 데이터 타입을 지정,accept 헤더는 클라이언트가 서버로부터 받고자 하는 응답의 미디어 타입을 지정한다.
구현한 테스트는 post 요청(/api/events)에 대한 테스트로 contentType 으로 해당 요청의 본문에 Json 을 담아서 보내고 있다고 알려주고 accept 헤더로 HAL_JSON 타입으로 응답을 원하고 있는지 알려준다.
테스트를 실행하면, 201 Created 코드를 기대했지만, 실제로는 해당 엔드포인트를 처리하는 Controller가 구현되지 않았기 때문에 404 Not Found 상태 코드가 반환되기 때문에 테스트가 실패한다.
이제 EventController 를 구현해보자
API 개발 시에 두 가지 주요한 반환 타입으로 ResponseEntity와 @ResponseBody 가 있다.
보통은 API의 복잡성과 요구 사항에 따라 두 가지를 조합하여 사용하는데 ResponseEntity는 HTTP 응답을 더욱 세밀하게 제어할 수 있는 반면, @ResponseBody는 컨트롤러 메소드의 반환 데이터를 간편하게 HTTP 응답의 본문으로 지정할 때 사용된다.
응답 코드, 헤더, 본문 모두 다루기 편한 API를 개발하기 위해 ResponseEntity를 반환타입으로 사용.
ResponseEntity.created 를 보내기 위해서는 항상 URI 가 필요하기 때문에 Location URI 만들기 위해 HATEOS가 제공하는 linkTo(), methodOn() 사용하여 URI 를 만들어서 반환하였다.
다시 테스트를 돌러보면 다음과 같이 성공하는 것을 볼 수 있다.(andDo(print()) 를 사용하여 어떤요청을 보냈고 어떤 응답을 보냈는지 확인할 수 있다.)
2. EventRepository 구현 후 id는 DB에 들어갈 때 자동생성된 값으로 나오는지 확인
Event를 Entity 로 선언
id 값 만들어 주고 @Enumerated(EnumType.STRING)으로 변경
EventRepository 생성
EventController 수정
@RequestMapping을 선언하여 methodOn 제외, produces = MediaTypes.HAL_JSON_VALUE 를 사용하여 해당 컨트롤러의 모든 메소드가 생성하는 응답이 JSON 형식으로 HAL(Hypertext Application Language) 포맷을 따르는 것을 나타냄
전달받은 event를 save 하고 ResponseEntity의 body 에 전달.
EventControllerTests 수정
Mockito를 사용해서 mock 객체를 만들고 빈으로 등록해 준다.
Mock 객체인 eventRepository의 save() 메서드가 호출될 때 이벤트 객체를 리턴하도록 설정합니다.
objectMapper.writeValueAsString(event)를 사용하여 event 객체를 JSON 문자열로 변환하고, 이를 요청의 본문에 포함
andExpect()를 사용하여 응답 본문에 id 필드가 존재하는지 확인하고, Location 헤더가 존재하는지 확인하여 새로 생성된 이벤트의 위치를 확인, Content-Type 헤더가 HAL JSON 형식인지 확인한다.
EventControllerTests 결과(성공)
