사실 면접질문에서 한번 나오긴 했는데, 그냥 에헤헿 코드짤 땐 찾아보고 써야지! 했는데
명확하게 언제 어떤 에러코드를 써야할지 모르겠어서 적어보는 포스팅.
그리고 과제테스트에서 내가 너무 지멋대로 써가지고 바보같아서 내가 보려고 쓴다 진짜
HTTP 상태코드?
HTTP 통신을 할 경우, 응답에 무조건 상태코드라는 것이 따라온다.
그것을 통해서 어떤 문제가 있고 그런 것을 판별할 수 있는데. 큰 범위는 5가지로 나눠져있다.
- 1xx 응답
- 2xx 성공적 응답
- 3xx 리다이렉트
- 4xx 클라이언트 에러
- 5xx 서버 에러
여기서 알아볼 것은 바로 4xx 클라이언트 에러에 대해 알아보고, 언제 쓰면 좋은지 적어보려고 한다.
왜냐하면 백엔드에서 로직 짤 때 에러 발생하면 상태코드에 맞게 리턴해줘야 문제를 빨리 해결할 수 있기 때문이다(...)
4xx 에러코드
NestJS에 빌트인 되어있는 상태코드 중 400번대만 가져와봤다.
많이 써봤던 것들 위주, 혹은 써볼 것 같은 것만 적어보려고 한다.
다 쓰기엔 너무 많고 제대로 알지 못하는 것들이 대부분이라서.
400번 BAD_REQUEST
서버에서 지정하지 않은 형태의 요청을 했을 때 사용한다.
지금 생각해도 왜 그랬는지 모르겠는 행동 중 하나가
과제테스트에서 요청하는 값이 없으면 에러코드 400번을 때려버린 것인데
NestJS에서는 유효성검사가 빌트인 되어있는데
서버에서 지정한 타입과 다른 타입으로 요청을 보낼 경우 에러코드 400번이 발생한다.
401번 UNAUTHORIZED
요청한 리소스에 대한 인증 자격이 없을 때 사용한다.
인증이 제대로 되지 않았다. 의 의미로 많이 사용한다고 하는데
나같은 경우에는 로그인을 시도했을 때, 아이디 혹은 비밀번호가 틀린 경우에 사용했다.
402번 PAYMENT_REQUIRED
결제가 필요한 경우에 사용한다.
나는 아직 써보지 못한 상태코드인데, 설명만 봐도 언제 써야할지 딱 보이는 것 같다.
유료 강의 혹은 구독 시스템이 필요한 사이트에서 미결제 상태로 클릭을 했을 때 반환하면 될 것 같다.
403번 FORBIDDEN
요청한 리소스에 대한 권한이 없을 경우 사용한다.
401번과 403번이 조금 헷갈려가지고 찾아봤는데 인증과 인가의 영역으로 나눠져있는 것을 확인했다.
관리자 권한이 필요한 작업인데 일반 유저가 눌렀을 경우 사용하면 될 것 같다.
404번 NOT_FOUND
요청한 정보를 찾을 수 없을 때 사용한다.
이건 개발자가 아닌 사람이라도 툭하면 보는 그것이다.
요청한 값이 디비에 없을 경우에 사용하고 있다.
405번 METHOD_NOT_ALLOWED
허용되지 않는 메소드로 요청이 들어올 경우 사용한다.
NestJS는 메소드를 다르게 던지면 404 에러코드를 반환하는데
일반적으로는 405에러가 반환된다고 한다(...)
미들웨어를 만들때? 헤더와 바디를 확인해가지고, 메소드가 다르게 들어올 때 사용하면 될 것 같다.
406번 NOT_ACCEPTABLE
요청을 이해했지만, 서버가 돌려줄 값이 없을 때 사용한다.
이거 404번이랑 뭐가 다른데(....) 일단 몇몇 사이트에서 이 코드를 반환하는 것을 봤는데
쿠폰이라던가 기프티콘을 등록할 때 해당 코드가 정상적이지 않거나, 이미 사용되었을 때 사용한다.
혹은 방화벽의 문제가 있을 경우 이런 것을 사용한다고 한다.
408번 REQUEST_TIMEOUT
말 그대로 리퀘스트의 시간이 초과되었을 경우 사용한다.
시간제한을 두고 로직을 짜본 적이 없는데, 특정 시간동안 작업을 해도 결과가 나오지 않을 때 사용하면 될 것 같다.
기약없이 해당 로직이 계속 돌고 있으면 문제가 될 수 있기 때문에, 그것을 방지하기 위한 목적이랄까?
409번 CONFLICT
요청이 서버와 충돌났을 경우 사용한다.
충돌이라고 하면 딱 생각나는 것은 역시 중복이라고 생각한다.
중복된 요청을 처리할 때 사용하면 될 것 같다. 나의 경우에는 유니크값인 중복 아이디를 요청보낼 경우 사용했다.
422번 UNPROCESSABLE_ENTITY
요청을 제대로 보내긴 했는데, 서버에서 처리를 못할 때 사용한다.
이것도 이해가 안가는데....
잘보냈는데, 서버에서 처리를 못하면 5xx번대로 가야하는게 아닌가싶다
부트캠프에서 수업 진행할 때 그냥 맨날 쓰던 에러코드였는데 음...
뭔가 정보를 은닉하고 싶을 때 사용하는 것인지? 애매모호한 것 같아서 이건 찾아봐야할 것 같다.
의문이 든 생각, 굳이 에러코드를 고민해야할까?
과거 많은 서비스에서는 비밀번호가 틀렸을 경우에 비밀번호가 틀렸으니 확인을 해달라는 에러문구가 나왔다.
그러다가 언제부터 갑작스럽게 둘 중 한개만 틀려도 아이디 혹은 비밀번호를 확인해달라는 메세지가 나오는 것으로 바뀌었다.
이렇게 바뀌게 된 이유는 단순하다고 생각한다.
경우의 수를 늘리는 것으로 보안 수준을 높혔다.
그렇게 생각을 해보니, 올바른 에러코드를 반환하는 것이 올바른 것인가?에 대한 의문이 생겼다.
이곳저곳 사이트를 찾아다니면서 확인을 해봤는데
콘솔창을 켜놓고 이것저것을 누르다보면, 에러코드가 뜨는 곳과 안뜨는 곳이 나눠져있는 것을 볼 수 있었다.
콘솔창에 에러가 뜨지 않는 곳들은 그럼 어떻게 에러핸들링을 하는 것일까?
그냥 try catch에서 문제가 발생하면 에러를 던지는 것이 아니라 falsey한 값을 프론트에 넘겨주고,
그것으로 체크를 하는걸까 라는 궁금증이 생기고 말았다.
알아낼 방법이 없고, 에러코드를 알맞게 던지라고 해서 고민해서 적고는 있지만 뭔가 의구심이 들고 있는 상태랄까? 이 의문을 언제 풀 수 있을지는 모르겠다.
끝
