HTTP 상태 코드

요즘 백엔드를 만지작 거리면서 계속 '이런 상황에서는 내가 어떤 상태코드로 리스폰스를 돌려보내야 하는 거지?'하는 의문이 들었다. 프론트 할 때는 크게 신경쓰지 않고 대충 숫자가 200대면 문제 없구나, 300대면 어디 다른 데로 가야하는 구나, 400대면 내가 문제가 있구나, 500대면 서버가 문제가 있구나 하면서 했는데, 내가 직접 돌려보내줘야 하는 순간이 찾아오니 한 번 제대로 짚고 넘어가야할 것 같은 느낌이 든다.

그래서 오늘은 자주 사용하게 될 상태 코드와 더불어 nestjs에서 각각을 다루는 메소드도 정리해보려 한다.

성공 응답

여기는 따로 nestjs 메소드가 없다. 아마도 각각의 orm이나 odm이 create update delelet find 등에 따라 알아서 상태 코드까지 리턴해주는 게 아닐까 싶다. 익스프레스에서는 res.status(201).send(data)의 형태 혹은 res.sendStatus(204)의 형태로 쓰이는 듯하다.

• 200 OK : 요청 성공. 주로 get 요청 혹은 patch와 put과 같은 업데이트 요청에 대한 상태 코드로 쓰인다.

• 201 Created : 요청의 결과로 새로운 리소스가 생성됨. post 요청 혹은 일부 put 요청에 대한 상태 코드로 쓰인다.

• 204 No Content : 요청에 대해서 보내줄 수 있는 콘텐츠가 없을 때. 주로 delete 요청에 대한 상태 코드로 쓰인다.

클라이언트 에러

400번대 에러는 클라이언트 쪽의 실수 혹은 문제로 인해 발생하는 에러를 모아두고 있다. 여기서부터는 nestjs 메소드가 있다. 사용 방법은 간단한데, 에러 이름 뒤에 Exception을 붙이는 것이다.

가령 로그인하지 않은 유저가 로그인해야 사용할 수 있는 유료 서비스에 접근한다면 1) 로그인도 안 되어있고 2) 돈도 안 냈지만 둘 중에 더 우선으로 확인하는 것은 403이 아닌 401이다. 따라서 throw new UnauthorizedException("로그인이 필요한 서비스입니다")를 던지면 된다.

• 400 Bad Request : 서버가 예상한 필드가 다 오지 않는 등 문법적으로 잘못된 요청일 때.

• 401 Unauthorized : 로그인 하지 않은 사용자가 로그인해야 하는 서비스에 접근할 때.

• 403 Forbidden : 권한이 없는 사용자가 권한이 필요한 서비스에 접근할 때.

• 404 Not Found : 미리 정한 필드 다 채워주고, 로그인도 하고, 권한도 있는데 서버에서 요청받은 리소스를 찾을 수 없을 때.

• 409 Conflict : 요청이 서버의 정책과 충돌될 때. 가령 닉네임은 Unique 필드인데, 누군가 이미 존재하는 닉네임으로 회원가입을 시도할 때.

• 418 I'm a teapot : 서버는 커피를 찻 주전자에 끓이는 것을 거절합니다.

서버 에러

500번대 에러는 클라이언트 쪽에서 문제 없이 요청을 보냈지만 서버의 문제로 인해 제대로 응답할 수 없는 경우 발생하는 에러를 모아두고 있다. 여기도 클라이언트 에러와 마찬가지로 nestjs 에러 처리 메소드를 사용할 수 있다.

• 500 Internal Server Error : 서버가 요청을 처리하는 방법을 알지 못할 때. (백엔드 개발자 잘못이다)

• 503 Service Unavailable : 서버가 요청을 처리할 준비가 되지 않은 상태

여담

나는 아마도 클라이언트 에러 쪽을 아주 자주 사용하게 될 것 같다. 이 글을 정리하면서 느낀 건데 특히 400번대 에러는 백엔드 개발자가 확인해야할 순서대로 번호가 매겨져있는 것 같다.

일단 클라이언트가 요청에 필요한 필드를 다 채워서 보내는 게 먼저고, 로그인이 되어있는지를 확인하고, 로그인 되어있더라도 권한이 있는지를 확인해야하며, 모든 게 다 완벽해도 서버에 필요한 리소스가 없을 수 있다(아마도 api params에 id 값을 잘못 넣어준 케이스가 많을 듯). 이 모든 게 다 제대로 들어왔다 해도 위의 닉네임 예시처럼 서버의 정책상 클라이언트의 요청을 수행해줄 수 없는 경우가 있을 것이다.

필드도 다 채워지고 로그인 후 권한이 존재하고 서버에 리소스가 있으며 서버 정책도 요청을 만족하지만, 서버가 커피를 찻 주전자에 끓이는 것을 거절할 지도 모르는 일이다.