Response 형태에 대해 질문드립니다.

Question

안녕하세요 백엔드 개발자를 희망하는 취준생입니다.기초적인 내용인거같지만 프로젝트를 정리하던 중 궁금한 부분이 생겨 질문드립니다.보통 request에 대한 response의 형태를 통일화 하는 부분에 대한 질문입니다. 기업마다 다르겠지만 successCode와 resultCode, resultMessage 등을 사용하는데 각각의 차이를 모르겠습니다.제가 참고하고 사용하는 Response는 아래와 같은 형태를 사용합니다.{ &#34;successCode&#34;:&#34;&#34;, &#34;resultCode&#34;:&#34;&#34;, &#34;resultMessage&#34;:&#34;&#34;, &#34;data&#34;:&#34;&#34;, &#34;error&#34;:&#34;&#34; }error는 error가 발생했을 경우에 에러 상세내용을 표시해주는 필드인데헤더에 HttpStatus를 표현하면 위의 코드들이 필요한가 싶기도 하고 왜 굳이 successCode와 resultCode, resultMessage 3개를 사용하는지 이해가 되지 않습니다.지금까지는 HttpStatus는 무족건 200으로 보내고{ &#34;successCode&#34;:true, &#34;resultCode&#34;:&#34;200&#34;, &#34;resultMessage&#34;:&#34;SUCCESS&#34;, &#34;data&#34;:{data}, &#34;error&#34;:&#34;&#34; }혹은{ &#34;successCode&#34;:false, &#34;resultCode&#34;:&#34;400&#34;, &#34;resultMessage&#34;:&#34;ERROR&#34;, &#34;data&#34;:null, &#34;error&#34;: {[&#34;field&#34;: &#34;길이 부족&#34;]} }이런식으로 사용해왔습니다.제가 느끼기엔 successCode와 resultCode, resultMessage가 모두 같은 기능을 한다고 해석됩니다. successCode가 요청을 성공적으로 처리하였다는 코드라면 ResultCode와 resultMessage는 읽을 필요가 없는 것 아닌가요..?resultCode만 봐도 판단이 가능한데 굳이 message를 통해 error를 알려줘야하는 필요가 있는지 궁금합니다.정확히 저 message가 어떤 용도인지 궁금합니다. ResultCode가 400으로 나갔는데 굳이 Message에 &#34;ERROR&#34;를 보내줘야하는 이유가 있나요??또 바디에서 저렇게 에러에 대한 코드를 처리한다면 reponse보내는 HttpStatus는 200으로 내보내는것이 맞나요..?저는 저렇게 사용하고 있었지만 다른 분 코드에서{ &#34;resultCode&#34;: &#34;ERROR&#34;, &#34;data&#34;: { &#34;password&#34;: &#34;영문, 숫자, 특수문자를 포함한 10~20자리로 입력해주세요&#34; }, &#34;message&#34;: &#34;에러가 발생했습니다.&#34; }이런식으로 사용하시면서 HttpStatus를 400으로 반환하는 코드를 보게 되어서 resultCode와 message를 둘 다 사용하는 이유가 궁금합니다. 기초적인 내용인데 질문이 많아서 죄송합니다ㅜ

남느 · Answer

요청에 대한 응답이 정상적으로 이뤄졌어도 사용자에게 오류 메세지를 보여줘야 할 때가 있습니다.HttpStatus 400이 아니라 200으로 한 다음,A라는 문제가 있는데 진행할까요? 예 / 아니오라는 메세지를 띄워야 할 수도 있죠.그리고 내부적으로 사용하는 프레임워크에서 저런 데이터들을 항상 보내기로 했을 수도 있죠.자바스크립트에서는 함수에 파라미터가 5개를 지정했을 때 3개만 전달되어도 문제가 되지 않지만,옛날 자바에서는 파라미터에 값이 하나라도 없는 경우 문제가 발생해서, 파라미터 개수에 맞춰서 메서드를 만들거나 예외처리를 해줘야 했으니 그 때 코드가 아직 남아있을 수도 있습니다.

캐티 · Answer

http헤더의 상태 코드는 어플리케이션 코드로 치환하지 않는 것이 적절해요. 이것은 http 프로토콜의 통신사이에 결과를 출력하는 것이므로 어플리케이션 상태코드는 추가 헤더나 바디에 넣어주는 것이 좋아요.restapi에서 상태 메세지는 다국어, l18in으로 인하여 프론트엔드에서 처리하면 좋아요.이 밖에도 고려할 것이 많아요. 하찮은 기능이라면 주의 사항은 무시하여도 무난한 편이었어요.

메로나한입만 · Answer

400 에러여도 여러 상황에서 터질 수 있으니까 프론트측이 개발하기 편하게 메세지도 함께 응답해주는거죠프론트측에서 필요없다고 하면 빼도 상관없습니다

chytonpide · Answer

타당한 의문인것 같구요. 님 생각이 맞는것 같습니다.저라면, http 프로토콜에 status code가 있는데, 페이로드 굳이 중복되는 정보를 담지 않을 것 같습니다.시스템 내에서(FE, BE간에) 분류를 위해서 약속한 errorCode가 있다면 errorCode 랑,API 사용자에게 의미가 있도록 errorMessage 만 에러 스키마에 정의해서 사용할 것 같아요.FE 측에서 미들웨어로 통신결과에 대한 처리를 일괄적으로 하기 위해, 특정한 스키마를 사용하고 있고, BE 측에서 그것에 맞춰서 리스폰스를 돌려줄 수 는 있는데,FE, BE간 결합이 강해서 별로 좋은 설계는 아닌 것 같습니다. 의존방향을 따지자면 FE가 API를 제공한는 BE를 의존하고, BE는 자기 클라이언트가 누군지 모르는게 맞죠.

장독깨기 · Answer

successCode 와 resultCode 가 중복이고, resultMessage 와 error 가 중복이네요.저 같은 경우, https status code 는 어느 구간에서 발생할지 모른다 생각해서 무조건 200 OK 로 합니다.

닉네임없음 · Answer

나온지 조금 되긴했는데.org.springframework.http.ProblemDetail이 class에 대해서 한번 알아보세요.

개미와고양이 · Answer

결과 객체의 포멧 유형은 정하기 나릅입니다.보통은 간소화 하기도 하고 특정 코드 successCode 나 resultCode 를 통합하기도 하는데성공과 실패 정보를 이분법 적으로 successCode 를 통하여 제공하는 경우실패인 경우에 따른 분류를 resultCode 통해서 세분화하고 그에 따라서메시지를 주거나 화면에서 취해줘야 하는 엑션을 다르게 해주는 역활을 합니다.

Response 형태에 대해 질문드립니다.

7개의 답변

#response 목록