ResponseEntity
프로젝트3일차
열심히 내가 맡은 부분을 개발중이다!
API를 작성하면서 반환타입을 좀 고려하게되고 해당 도메인의 객체만 반환하는것에서 끝나는게 아니라 상태코드를 같이 반환하면 더 도움이 될거라고 생각했다.
이번 프로젝트의 경우 반환값을 ResponseEntity로 정해놨고 해당 메소드에 적합한 응답DTO로 반환했다.
올해 3월에 썼던 포스트에 ResponseEntity에 대한 내용이 조금은 나와있다.
간단하게말하면 Spring에서 HTTP응답을 생성하는데 사용하는 클래스이다.
ResponseEntity의 경우 다양한 형태로 쓰일 수 있는데 단순히 성공을 했다는 ok를 보낼 수도 있고, 조금 더 구체적인 내용을 반환할 수도 있다.
사용법
사용법을 더 자세히 알아보자.
ResponseEntity.ok()
return ResponseEntity.ok().build();
앞서말했듯 성공적인 응답을 반환하고자 할때 사용한다.
개발자들이 가장 좋아하는 200응답을 자동으로 반환하고, 문자열을 추가로 포함시킬 수 있다.
return ResponseEntity.ok("성공했습니다!")
ResponseEntity.status()
원하는 HTTP 상태 코드가 있다면 직접 지정할 수 있다.
ok()의 경우 성공을 했다는 내용만 알고 어떤 동작이 성공했는지는 본문 없이 알 수 없지만 status를 사용하면 조금 더 유연한 사용을 할 수 있다.
return ResponseEntity.status(HttpStatus.NOT_FOUND).build();
마찬가지로 문자열을 포함할 수 있다.
return ResponseEntity.status(HttpStatus.CREATED).build("생성 성공");
메소드들이 체이닝 방식으로 동작하기때문에 아래 코드처럼 상태코드뿐만아니라 헤더, 본문까지 설정가능하다.
return ResponseEntity.status(HttpStatus.BAD_REQUEST)
.header("Custom-Header", "Value")
.body("Invalid request");
Http Status Code
상태 코드에는 여러 종류 존재하기때문에 원하는 응답을 사용할 수 있다.
-
201 Created
새로운 리소스 생성시 사용된다. -
204 No Content
요청은 성공적이지만 반환 내용이 없음을 나타낼때 사용된다. -
400 Bad Request
잘못된 요청 처리시 사용된다. -
404 Not Found
요청한 리소스를 찾을 수 없을 때 사용된다. -
500 Internal Server Error
서버 오류 시 사용된다.
204 No Content
오늘 API를 만졌던 부분에서 고민했던 상태코드이다.
데이터 삭제시 반환할 값이 없기에 평소 return이 없는 void를 사용했다.
그런데 상태코드를 던지려면 어떻게해야하나 고민하다 204 No Content라는 것을 알게되었고
"오 이걸 쓰면 되겠다. 삭제는 성공했음을 알리고 아무것도 반환하지못하는건 당연한거니까"
라고 생각했다.
그런데, MDN에 있는 204 No Content와 관련된 글을 읽어보면 단지 본문없는 응답일 뿐이다라는 것을 알 수 있다.
만약 204 코드를 사용하고 다음과 같은 상황이 있었다면 어떨까?
CASE : 사용자가 삭제를 요청했지만 요청한 리소스가 존재하지않은 값일때
위의 상황에서 실제로 삭제할 값이 없었지만 본문없는 응답 코드를 던지며 클라이언트는 자신이 서버에 보낸 요청이 잘못됨을 인지하지 못하게된다.
RESTful 한 API에서도 일관된 응답 이 중요한 부분인데, 이 또한 본문을 적을 수 있느냐 없느냐가 중요한 부분이다.
명확한 피드백을 위해서는 본문을 적을 수 있는 다른 상태 코드를 사용하는게 좋아보인다.
고민과 해결
마지막으로 오늘 고민했던 내용이다.
나는 오늘 간단한 가게 CRUD 작업을 진행했는데, 이번 프로젝트에 평소와는 다른 조건이 하나 존재했다.
바로 이 내용.
평소같았으면 서비스단에서 Delete를 사용해서 해당 아이디에 맞는 값을 삭제하면 됐었는데, 데이터 보존을 위해 삭제처리 만 해야했다.
고민을 하고 팀원분이랑 이야기 해본 결과 앤드포인트로 Delete request를 보내지만 서비스단에서는 삭제처리 속성의 값을 true로 변경하는 방법을 적용하기로 했다.
결국 외적으로 봤을때는 사용자가 삭제를 요청하고 값이 프론트단에서 사라져야하기때문이다.
데이터보존 로직의 경우 백앤드 개발자에게 중요한 부분이지 사용자에게는 큰 차이가 없어야한다.
사용자는 단순히 삭제를 요청 -> 값 삭제된것처럼 보이기.
그래서 위와 같이 API를 구현해놨다.
마치며
내가 생각하기에는 너무 개발속도가 느려 효율이 조금 떨어지는 것 같다.
중간중간 모르는 것들을 적어놓고 공부하면서 하려니까 시간이 좀 더 걸리는 것 같다.
조금 더 속도내서 열심히 해보자 !
