HTTP 상태코드의 종류
1. 상태코드 (Status code)
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
- 1xx (Information): 요청이 수신되어 처리중. 잘 사용되지 않아 실무에서는 거의 볼 수 없다.
- 2xx (Successful): 요청 정상 처리.
- 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요.
- 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음.
- 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함.
2xx(Successful)
200번대에서 자주 사용되는 code.
-
200 OK
주로 GET 요청에서 많이 볼 수있다. 요청이 성공하면 응답에서 상태코드 200을 보내준다.
-
201 Created
요청이 성공해서 새로운 리소스가 생성된 경우 상태코드 201을 보내준다. 생성된 리소스의 경로는 응답의 Location 헤더 필드를 통해 확인.
-
202 Accepted
요청이 접수되었으나 처리가 완료되지 않은 경우 사용한다. 예를 들어 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리하는 경우를 말한다.
-
204 No Content
서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없는 경우 사용한다.
예를 들어 웹 문서 편집기에서 save 버튼을 누르는 경우- Save 버튼의 결과로 아무 내용이 없어도 되고
- Save 버튼을 눌러도 같은 화면을 유지해야 한다.
- 즉 결과 내용이 없어도 204 메시지만으로 성공을 인식할 수 있다.
3xx (Redirection)
요청을 완료하기 위해서는 유저 에이전트(웹 브라우저)의 추가 조치 필요하다는 의미로 보내주는 코드이다. Redirection 이란 3xx 응답의 결과에 Location 헤더가 있으면, 웹 브라우저는 Location URI로 자동 이동되는 것을 의미한다
-
영구적인 리다이렉션
특정 리소스의 URI가 영구적으로 이동하며, 원래 URL을 사용하지 않고, 검색 엔진 등에서도 변경을 인지 할수 있다.
-
301 Moved Permanently
리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다
-
308 Permanent Redirect
301과 기능은 같지만, 리다이렉트시 요청 메서드와 본문을 유지하는게 차이점.
실무에서는 거의 사용되지 않는다. (새로운 URL로 개편 되었을 경우, 새로운 URL에서 요구하는 데이터와 기존 URL에서 요구하는 데이터와는 다른 경우가 많기 때문에 자주 쓰이진 않는다.)
-
-
일시적인 리다이렉션
리소스의 URI가 일시적으로 변경되는 경우를 의미하기 때문에, 검색 엔진 등에서 URL을 변경하면 안 된다.
PRG ( Post / Redirect / Get)가 일시적인 리다이렉션의 대표적인 예시.
POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트를 하게 된다. 이렇게 하면 POST로 주문 후에 새로고침 해도 결과 화면을 GET으로 조회하기 때문에 결과 화면만 GET으로 다시 요청되므로 중복 주문을 방지할 수 있다.-
302 Found
리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거 될 수 있다.
실무에선 아직 302가 가장 많이 쓰이고 있으며, 크게 문제는 없다. -
307 Temporary Redirect
302와 기능은 같지만, 리다이렉트시 요청 메서드와 본문이 유지된다. POST로 요청 했다면 리다이렉트시에도 POST 요청을 해야한다.
-
303 See Other
302와 기능은 같고, 리다이렉트시 요청 메서드가 GET으로 변경 된다.
307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 사용하고 있다. 자동 리다이렉션시에 GET으로 변해도 되면 302를 사용해도 문제없다.
-
-
특수 리다이렉션
결과 대신 캐시를 사용해야 할 때 쓴다.
-
304 Not Modified
캐시를 목적으로 사용하고, 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트 로컬 PC에 저장된 캐시를 재사용한다 ( 캐시로 리다이렉트 ).
로컬 캐시를 사용해야 하므로 304 응답은 응답에 메시지 바디를 포함하면 안 된다.
-
4xx(Client Error)
클라이언트의 요청이 잘못된 문법 등으로 서버가 요청을 수행할 수 없을 때, 오류의 원인이 클라이언트 쪽에 있을 때 사용한다. 400대 상태 코드를 받은 경우, 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 재시도 해도 똑같이 실패한다. ( 프로젝트 때 오타로 인해 많이 겪어봄... ㅠㅠ )
-
400 Bad Request
클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없는경우 사용.
서버개발자들은 철저하게 validation해서 에러코드를 정확하게 보내줘야 한다. 그래야 클라이언트 개발자가 문제인식을 빠르게 할 수 있다. -
401 Unauthorized
인증(Authentication) 되지 않은 경우 사용한다. 401 오류 발생 시 응답에 WWW-Autenticate 헤더와 함께 인증 방법을 설명해 줘야 한다. (Authentication 인증과 관련)
-
403 Forbidden
서버가 요청을 이해했지만 승인을 거부하는 경우. 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우 사용한다. 예시로 Admin 등급이 아닌 사용자가 로그인은 했지만, Admin 등급의 리소스에 접근하는 경우를 말한다. (Authoriztion 인가와 관련)
-
404 Not Found
요청 리소스가 서버에 없는 경우 또는 클라이언트가 권한이 부족한 리소스에 접근하는 경우 해당 리소스를 숨기고 싶을 때 사용.
5xx (Server Error)
서버 문제로 오류가 발생했을 때 사용하며, 서버의 문제이기 때문에 문제가 해결되면 재시도 했을 경우 성공할 수도 있다.
-
500 Internal Server Error
서버 내부 문제로 오류가 발생한 경우 사용. 애매한경우 500 상태코드를 쓰세요..
-
504 Service Unavailable
서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없을 때 사용한다.
Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수 있다.
