API 응답값 중 뭐가 옳다고 생각하나요?

1. { movie: null } 이 응답은 해당 Movie가 존재하지 않는다는 것을 명확하게 나타냅니다. Movie 데이터를 찾을 수 없는 경우라면, 이 방식이 더 직관적입니다. 클라이언트 측에서도 쉽게 "이 Movie는 존재하지 않는다"고 판단할 수 있습니다. 2. { movie: { title: null, score: null } } 이 응답은 구조상 Movie 객체가 있지만, 그 내부 필드들이 null로 채워져 있는 상태를 나타냅니다. 이 경우, Movie 객체는 존재하지만 데이터가 없거나, 값이 비어 있다는 혼란을 줄 수 있습니다. 특히, 클라이언트 측에서 "null" 값을 실제로 전달된 값으로 오해할 가능성도 있습니다. { movie: null }이 더 옳다고 할 수 있습니다. 해당 Movie가 존재하지 않는다는 사실을 명확하게 전달해주기 때문에, API를 사용하는 측에서도 이를 명확히 이해할 수 있습니다. 데이터가 없는 상태와 해당 데이터가 존재하지 않는 상태를 구분하는 것이 중요한 경우, 이 방식이 더 적절합니다.

해당 경우에는 프로젝트 내부에서 특정한 규칙을 세워둔게 아니라면 404로 에러를 응답해주는게 가장 맞는 것 같습니다. 검색이나 필터 등으로 다건 조회를 하는 경우에는 데이터가 없다는것 자체가 잘못된 요청이 아니지만, 없는 데이터를 단건으로 요청하는 경우는 데이터가 없는데 요청하는 것 자체가 잘못된 접근일 가능성이 큽니다. 예를들어 상세페이지에서 아이디나 쿼리파람을 바꿔서 접근하거나 하는 식으로 하는 잘못된 접근일 경우겠죠 아래는 claude답변입니다. REST API에서 리소스를 찾을 수 없는 경우 처리하는 방법에 대해 좋은 질문을 하셨습니다. 특정 데이터 단건 조회 시 데이터가 없을 때 일반적으로 권장되는 방법은 다음과 같습니다: HTTP 상태 코드: 404 Not Found 가장 RESTful한 방식은 404 Not Found 상태 코드를 반환하는 것입니다. 이는 요청한 리소스를 서버에서 찾을 수 없음을 명확히 나타냅니다. 응답 본문: 404 상태 코드와 함께 간단한 JSON 응답을 제공하는 것이 좋습니다. 예를 들면: jsonCopy{ "status": 404, "message": "User not found", "details": "No user found with name 'A'" } 이 응답은 클라이언트에게 더 자세한 정보를 제공하여 왜 요청이 실패했는지 이해하는 데 도움을 줍니다. 일관성: API 전체에서 이러한 패턴을 일관되게 유지하는 것이 중요합니다. 모든 "리소스를 찾을 수 없음" 상황에서 동일한 구조의 응답을 사용하세요. 로깅: 서버 측에서는 이러한 "not found" 상황을 로깅하는 것이 좋습니다. 이는 디버깅과 사용 패턴 분석에 유용할 수 있습니다. 이 접근 방식은 HTTP 표준을 따르며, 클라이언트 개발자들이 쉽게 이해하고 처리할 수 있는 명확한 응답을 제공합니다.

일반적으로 데이터 모델링을 한다고 했을때, title과 score는 movie의 속성이라고 볼 수 있을겁니다. 그리고, json은 그 속성을 depth로 표현해주는 게 사람이 읽기도, 코드가 처리하기도 편합니다. 그래서 일반적으로 movie가 유효하다면 당연히 아래와 같은 형태일 겁니다. { movie: { title: "제목", score: 10 } } 하지만, 속성이 아닌 그 객체가 존재하지 않을때, 2번처럼 내부 객체를 다 풀어버리고 null화 해버리면 문제가 됩니다. 이는 개념적으로 not null하게 다룰수도 있는 하위 속성을 nullable하게 만들며 null을 남용하는 것과 다름없습니다. 이름(title)이라는 필드를 포함하여 데이터 설계상 null이 허용되지 않는 필드들이 있을 수 있습니다. 그럼에도 2번같이 사용하면, movie 하위 모든 필드는 nullable하다고 프론트에 공유해야하고, 프론트엔드는 null check를 모든 필드에 대해서 체크하는 번거로운 작업이 수반될 겁니다. 필드들이 늘어나게 된다면 더욱 귀찮아질 거구요. 또 depth가 지금은 단순하지만, 비즈니스가 복잡해지고 movie에 다양한 내용들이 들어가 그 depth가 늘어나게 된다면요? 2번 방식대로하면, 모든 하위 depth의 모든 필드들을 null로 나열해야만 하고 이는 의미없는 response 가 전달되는 걸로 보입니다. 또, 2번이 문제가 되는 경우를 살펴보면, 영화는 존재하는데, 나중에 그 속성으로 nullable한 필드(eg. 영화의 부제목)가 들어온다고 했을때 아래와 같을 겁니다. { movie: { title: “제목“, score: 4.9, subtitle: null } } 프론트엔드 입장에서 2번 방식을 사용하면 영화의 존재 여부를 판단하기 어려워집니다. 이를 해결하기 위해 억지로 "특정 필드들이 null이면 이건 movie가 없다고 쳐"와 같은 코드를 구성하게 되면 확장성/유지보수성이 크게 낮아지는 코드입니다. 결론적으로 1번이 조금 더 확장가능하고, 프론트엔드와 소통하기 편한 방식이라고 의견드립니다. 간단한 인터페이스를 짜보면 아래와 같겠네요. interface SingleResponseDto { movie: MovieDto | null; } interface MovieDto { title: string; score: number; somethingNullableField: string | null; } === 추가 === 1번과 2번 중에서 고르기때문에 1번이 맞다고 했지만, 보통 단일응답 API의 경우 해당 resource id 가 uri 등에서 특정되기 때문에 404 혹은 그에 적합한 오류 scheme을 반환하는 것을 더 선호합니다. 위의 답변은 객체 구조만 놓고봤을 때 보편적인 답변이 될 것 같습니다

2번 찍고 봤는데 지금보니 { movie: null, title: null, score: null } 이 아니였네요 2depth로 굳이 가야될 이유가 없으면 통일된 양식의 하나에 맞춰서 내려주는걸 좋아하는 편이라.. 다만 위의 케이스는 1번이 조금 더 적당해보이내요

1번. {movie : null} 보편적인 상황에서 문제될 게 없습니다. 2번. {movie : {title : null, score : null}} 언뜻 보면 괜찮은데, 나중에 문제될 수 있습니다. 당장 critical하지는 않은데 이런 게 누적되면 (경험 상...) 안 돼요. 저도 알고 싶지 않았는데요..하하 어쨌든 2번은 데이터 스키마를 고려한 방식에서 나온 발상 같은데요. 지금의 2번은 예외처리가 좀 힘들어요. 특히 클라이언트 - API 통신을 고려한다면 '통신 성공/실패', '데이터 있음/없음'처럼 바이너리(이진 형태)로 명확한 게 좋습니다. 저는 컴퓨터에서 뭐든(?) 바이너리를 기준으로 하면 케이스가 깔끔하게 정리된다는 이상한 관념이 있어요. 이런 기준은 때로 좋은 가이드가 된답니다. 제가 생각할 때 데이터 스키마를 한 눈에 보여주면서도 나쁘지 않은 대안은 아래 같아요. 이러면 모든 value 와 key 쌍에 명확한 요청과 확인이 가능하리라는 판단입니다. {movie : null , title : null, score : null} 근데 아무래도 1번이 제일인 것 같네요. 이유는 그냥.. 군더더기 없잖아요. 그게 최고라구요(?)

1번 `{ movie: null }`이 옳다고 생각합니다. 클라이언트 입장에서 2번의 응답이 올 경우 데이터가 있다 없다를 판별하는 기준이 굉장히 모호하지 않을까요? 1번은 `data.movie === null`로 판별할 수 있지만, 2번은 `data.movie.title === null && data.movie.score === null` 요런 식으로 판별해야 하는데 조건식도 복잡해지고, 유지보수도 어려워 질 것 같아요.

헐 이거 반반인 거 너무 신기하네요. 전 당연히 1번이 압도적일 줄 알았는데!

원론적으론 1이 맞다고 생각하는데 프로젝트 상황마다 다를 것 같습니다

오잉 투표는 반반인데 댓글은 다들 명확하게 1번을 선호하시네요. 2번 투표하신분들 의견도 듣고싶은데(?)

1번이 맞다고 생각을 하고 투표를 했다가 2번도 맞다고 볼수 있겠다는 생각이 들었습니다 너무 꼬아서 생각할수도 있는거지만 속성값이 꼭 not null 이어야 하는거로 생각이 들었습니다 id 발번만 되면 movie 라는 객체가 생성이 되고 그에 따른 데이터가 내려가서 수정을 요구 할수 있는 상태가 되지 않나? 하는 생각이 들었어요