http response에 대한 회고록

J·2023년 2월 10일
0

웹 공부

목록 보기
2/9

web front 개발자로서 오랫동안 http 프로토콜을 사용했지만
어떻게 response status를 다뤄야 잘 다뤘다고 소문이 날까 고민을 해왔다.

이번 프로젝트도 어김없이 axios를 사용하고 있고 처음으로 typescript를 사용하고 있다.

이번에는 axios의 interceptor를 사용해 보고 싶은데 어떻게 사용하는지는 알겠지만 error status 처리를 어떻게 자동화 할지에 대한 고민을 많이 했다.

default non-error status

먼저 axios에서는 default로 200~300 사이의 status를 error로 간주하지 않는다.
이 범위를 임의로 늘릴수 있는데 사용자 인증이나 서버 문제까지 non-error로 간주해 처리하는것은 로직상 좋아보이지는 않았다.


axios config <- 이곳에서 확인할 수 있다

server logic

그렇다면 서버에서 특정 상황에 따라 status를 다르게 주면 어떨까?
사용자 정의 exception을 통해 status를 보내도록 해봤다.

try{
	const response = await axios.get("/");
}
catch(error){
	const {response} = error as unkown as AxiosError;
  	if(response?.status){
    	//...
    }
}
 

구글링을 하다가 이렇게 처리하는 예제도 발견했다.
javascript는 error가 unknown 타입이라서 저렇게 해줘야한다고 한다. 이 방식은 작동은 하지만 저 as 키워드는 특정 타입으로 간주하는거라서 좋은 코드는 아니라고 한다

그리고 response에 error status를 담아서 보내는것은 restful api를 사용하더라도 이 동작에 대한 결과를 내포하는 것이라고 생각돼 보안상으로 좋지 않은 방식인거 같다.

결론

여러 참고 글을 찾아다니고 생각해본 결과로서는
server와 client가 합의하에 새로운 객체에 status를 지정해주는것이 좋겠다고 결론이 났다.

실제 response.status는 200이지만
서버의 처리 결과에 따라 새로운 status 값을 보내 client가 그것을 해석해 처리하는게 좋아보인다.
물론 404나 500 같은 치명적인 오류까지 커스텀 해버리면 안된다.








프로젝트를 하다 나온 주관적인 생각이라 정답이 아닐수도 있습니다. 생각을 정리하고자 적은것이니 틀리거나 더 좋은 방식이 있다면 댓글 부탁드립니다 ^,^

0개의 댓글