공통 응답 객체가 필요한 경우가 있나요?

Question

안녕하세요. 형제님들 간만에 오키 형제님들의 의견이 궁금해지는 주제가 생겨서 글 남기고 갑니다.조직마다 CommonResponse, ErrorResponse라고도 쓰이는 공통 응답 객체의 필요성에 대해 어떻게 생각하시는지 궁금합니다.일반적으로 공통 응답 객체에는 status와 description이 포함됩니다. (어디간에서는 errorCode와 errorDesc 라고도 많이들 쓰시는 것 같구요)사실 저는 요청이 성공하면 status는 Success, description은 반환값을 통해 알 수 있다고 생각해서 공통 응답 객체의 사용에 회의적입니다. 저는 제공되는 ResponseEntity를 사용하여 HTTP 헤더에 결과 상태코드를 넣으면 된다고 생각하는데 회원님들은 어떻게 생각하시나요??물론, 응답이 실패했을 때는 그 응답이 왜 실패했는지 정도는 클라이언트에 알리는게 좋다고 생각합니다만 사실 이 부분도 그냥 ResponseEntity 잘 쓰는게 좋지않은가 싶기도합니다.

장독깨기 · Answer

저 같은 경우도, 아주 오래전에 작성해서 사용해왔지만, 상태코드, 메시지를 별도로 공통으로 두고 처리해왔는데요,실패 시 그 사유를 어케 전달할 방법이 있는건가요.가령, 특정 항목 필수 값 입력 오류가 발생하면 클라이언트가 어케 알 수 있는거죠.

캐티 · Answer

모델이요 .. 공용 모델은 권장되는 디자인 패턴이고, 응답 상태는 사실 http status code 와 app status code 는 다른 것이어서 나눠주어야 해요. 서버 응답이 항상 성공한다고 가정하면 http 응답 코드를 덮어쓰는 방식으로 하여도 좋을 것인데요.http 5xx가 뜨면 앱 상테가 출력이 안 될 수도 있겠지만 .. 가능하다면 error, backplane server timeout 이라고 출력하고 각각 오류 코드를 나누어 처리하고 피드백을 받는 것이 좋지 않겠나요.

kotliner · Answer

http 헤더는 표현력이 빈약합니다. 똑같은 404여도 어떤 엔티티의 부재이냐에 따라 클라이언트의 대응방법이 엄청 바뀌기도 하고 400이나 500은 말할것도 없이 추상적이구요. 어떤건 점검이라서 그냥 alert만 하면 되는데, 어떤건 심각한 오류라서 다르게 처리해야할수도 있습니다.클라이언트에서는 이러한 에러를 다이얼로그, 토스트, 에러 분기 동작 등 다양한 방법으로 대처하게 되는데, 그 과정에서 공통된 객체가 없다면 클라이언트에서는 모든 응답에 에러를 위한 필드를 매번 선언해줘야합니다. 이건 서버도 마찬가지구요. 결국 수백개 수천개의 중복되는 에러 필드를 하나로 합치는게 당연한 선택지가 됩니다.

공통 응답 객체가 필요한 경우가 있나요?

3개의 답변

Q&A 목록