리소스가 없을 수도 있는 API에 대한 고민

개요

사용자의 위치 정보를 조회하는 API가 추가됐다.
위치 정보는 한 유저가 하나의 위치정보만을 갖고 있기에 me 기반 조회로 설계했다.

GET api/v1/members/me/location

해당 API는 요청한 유저의 위치 정보가 없을 경우 404 Not Found를 반환한다.
그러나 FE 측에서 해당 정보는 필수 입력 정보가 아니기에 404 에러 발생에 대해 검토를 제안했다.

두가지 선택지 중에서 204 No Content를 명시하도록 제안했다. 그러나 해당 방식에 대해 확신이 들지는 않았기에
RFC 표준스펙에서는 204 응답이 어떤 의미이며 기존 방식 혹은 제안해준 방식도 검토하여 방향성을 정하기로 했다.

요청에 대해서 보내줄 수 있는 콘텐츠가 없지만, 헤더는 의미있을 수 있습니다.
사용자-에이전트는 리소스가 캐시된 헤더를 새로운 것으로 업데이트 할 수 있습니다. 출처: MDN

핵심은 body에 값을 넣지 않도록 설계됐다는 점이다.
이에 대응하여 일부 프레임워크에서는 204 응답에 대해 body의 본문을 무시한다고 한다.

GET 요청은 대상 리소스에 대한 현재 선택된 표현의 전송을 요청하는 것이다.

대상 리소스를 서버가 찾을 수 없다는 404 Not Found 또한 충분히 표준에 맞는 응답이다.

성공과 데이터 없음을 표현하는 것이 과연 괜찮을까? 1:1 대응 관계에서 리소스가 없다면 null를 반환할 수도 있다고 json api 스펙에서 언급한다.

현재는 위치 정보를 입력 여부에 따른 사용자를 구분할 필요가 없다. 또한, 위치 정보는 필수 입력값이 아니기에 사용자 기준으로 위치 정보를 조회하는 것이 클라이언트 오류라고 해석하기에는 어렵다고 판단하여 200 + null로 결정했다.

404 Not Found
- GET 요청에 대한 리소스가 없는 것을 명확히 표현
- 위치정보를 입력하지 않은 유저가 페이지 진입하는 것 만으로 클라이언트 오류로 해석
200 OK + null
- GET 요청에 대한 성공과는 별개로 리소스의 여부는 body 내부 값으로 표현
- 사용자가 위치 정보를 갖고 있음 여부를 구분할 필요가 없을 때
- body 내부 data 자체가 nullable
204 No Contents
- 요청한 리소스가 없음을 명시
- body에 값이 없기에 http status로 분기 처리 필요
  - 200 → body 확인
  - 204 → 데이터 없음 간주