HTTP Status Code

1. HTTP Status Code (상태 코드)

클라이언트가 서버에 HTTP 요청을 보냈을 때 정상적으로 처리되었는지 아니면 에러가 발생했는지 알려주는 것이다. 클래스의 정의만 지킨다면 RFC2616에서 정의된 상태 코드를 변경하거나, 서버 독자의 상태 코드를 만들 수 있다. 

HTTP 상태 코드는 60종류 이상이 있지만, 그 중에서 대표적으로 사용되는 상태 코드를 살펴본다.

2. 응답 상태 코드

2.1 2xx: 성공(Success)

2xx 응답은 클라이언트의 요청이 정상적으로 처리되었음을 나타낸다.

① 200 OK

클라이언트가 보낸 요청을 서버가 정상 처리하였음을 나타낸다. 응답할 때 상태 코드와 함께 되돌아 오는 정보는 메소드에 따라 다르다.

② 204 No Content

이 응답은 서버가 요청을 받아서 처리하는 데는 성공했지만, 처리할 데이터가 없는 경우다. 예를 들어 클라이언트에서 '게시판 조회'를 요청했는데 게시판에 글이 없는 경우다.

③ 206 Partial Content

범위가 지정된 요청에 의해서 서버가 부분적 GET 요청을 받았음을 나타낸다. 응답에는 Content-Range로 지정된 범위의 엔티티가 포함된다.

2.2 3xx: 리다이렉트(Redirection)

3xx 응답은 요청을 정상적으로 종료하기 위해 클라이언트 측에서 특별한 행동을 수행해야하는 것을 나타낸다.

① 301 Moved Permanently

요청된 리소스에는 새로운 URI가 부여되어 있기 때문에, 이후로는 그 리소스를 참조하는 URI를 사용해야 한다는 것을 나타낸다. 북마크하고 있는 경우에 Location 헤더 필드에서 가리키고 있는 URI에 북마크를 다시 하는게 좋다는 것을 나타낸다.

② 302 Found

요청된 리소스에는 새로운 URI가 할당되어 있기 때문에 그 URI를 참조해달라는 의미다. 301과 비슷하지만 302의 경우에는 영구적인 이동이 아니라 일시적이다. 즉, 이동하는 곳의 URI는 앞으로 이동될 가능성이 있다.

③ 303 See Other

요청된 리소스는 다른 URI에 있기 때문에 GET 메소드를 사용해서 얻어야 한다는 것을 나타낸다. 302 Found와 같은 기능이지만, 리다이렉트 장소를 GET 메소드로 얻어야 한다고 명확하게 되어 있다는 점이 302와 다르다.

2.3 4xx: 클라이언트 에러(Client Error)

4xx 응답은 클라이언트가 잘못된 요청을 했을 때 에러가 발생했음을 나타낸다.

① 400 Bad Request

요청 구문이 잘못되었음을 나타낸다. 이 에러가 발생한 경우, 요청 내용을 재검토하고 다시 시도할 필요가 있다. 대표적으로 REST API를 사용할 때 서버에서 지정한 구문을 충족시키지 않았을 때 발생한다.

② 401 Unauthorized

클라이언트가 요청했을 때 HTTP 인증 정보가 필요하다는 것을 나타낸다. 예를 들어, 회원만 사용 가능한 페이지에 비회원이 접속했을 때 발생한다.

③ 403 Forbidden

요청된 리소스의 접근이 거부되었음을 나타낸다. 서버 측에서 거부할 이유를 명확하게 해야 할 경우에는 엔티티 바디에 기재해서 클라이언트 측에 표시해준다. 대표적인 원인으로는 파일 시스템의 권한이 부여되지 않은 경우가 있다.

④ 404 Not Found

요청한 리소스가 서버에 없다는 것을 나타낸다. 주소를 잘못 입력했을 경우 발생한다.

2.4 5xx: 서버 에러(Server Error)

5xx 응답은 서버 원인으로 에러가 발생하고 있음을 나타낸다.

① 500 Internal Server Error

서버에서 요청을 처리하는 도중에 에러가 발생하였음을 나타낸다. 웹 애플리케이션에 에러가 발생한 경우나 일시적인 경우도 있다.

그리고 서버는 소통을 하지 않는 것이 보안적인 측면에서 더 좋기 때문에 서버 에러를 대부분 500으로 통일해서 응답한다.

② 503 Service Unavaliable

일시적으로 서버가 과부하 상태이거나 점검 중이기 때문에 현재 요청을 처리할 수 없음을 나타낸다. 티켓 예매 사이트에서 발생하는 경우가 많다.

3. 마치며

HTTP 상태 코드를 명확히 알고 있어야 RESTful API로 프론트 개발자와 백 개발자가 더 원활하게 소통할 수 있다. 이전에 회원가입 기능을 만들고 있을 때 회원가입 정보를 서버 측에 잘못 넘겨서 400 에러가 발생했는데 그것을 서버 측에 버그처리를 요청했던 적이 있다. 4xx는 클라이언트에서 잘못된 정보를 보냈을 때 발생하는 에러인데 말이다. 역시 아는 만큼 보이는 법이다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Status에 접속하면 여기에 정리된 상태 코드 이외의 것들도 알 수 있다.