.png)
상태 코드
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
1xx (Informational) : 요청이 수신되어 처리중 < 거의 사용 안됨
2xx (Successful) : 요청 정상 처리
3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요
4xx (Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함
미래의 새로운 상태 코드가 추가되어도 클라이언트는 상위 상태코드로 해석하기 때문에, 클라이언트를 변경하지 않아도 됨. > 299 > 2xx (Successful)
1xx (Informational)
거의 사용하지 않음
2xx (Successful)
200 (OK)
- 요청 성공
- 주로 GET 메서드로 조회하는 경우
201 (Create)
- 요청 성공해서 새로운 리소스가 생성됨
- POST의 경우 Server에서 자원을 생성함
202 (Accepted)
- 요청이 접수되었으나 처리가 완료되지 않았음
- 배리 처리 같은 곳에서 사용
- 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함
204 (No Content)
- 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 본문에 보낼 데이터가 없음
- 웹 문서 편집기에서 save 버튼
- save 버튼의 결과로 아무 내용이 없어도 된다.
- save 버튼을 눌러도 같은 화면을 유지해야 한다.
3xx (Redirection)
요청을 완료하기 위해 유저 에이전트(보통 브라우저)의 추가 조치 필요
웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트)
자동 리다이렉트 흐름
- 서버에 페이지 요청
- 서버는 3xx과 Location을 준다
- 브라우저는 Location 페이지를 요청
- 서버에서 2xx응답과 새로운 페이지를 준다.
영구 리다이렉션
- 특정 리소스의 URI가 영구적으로 이동 (301, 308)
- ex) members > /users
- 리소스의 URI가 영구적으로 이동
- 원래의 URL를 사용 안함, 검색 엔진 등에서도 변경 인지
301 (Moved Permanently)
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 (무조건 아님)
308 (Permanent Redirect)
- 301과 기능은 같음
- 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST)
페이지 이름이 바뀌였기 때문에, 입력 데이터도 변경될 가능성이 많기 때문에, 301을 주로 사용함.
일시 리다이렉션
- 일시적인 변경
- 리소스의 URI가 일시적으로 변경
- 따라서 검색 엔진 등에서 URL을 변경하면 안됨 (A→B or A→C)
- 주문 완료 후 주문 내역 화면으로 이동
302 (Found)
- 리다이렉트시 요청 메서드가 GET으로 변할 수 있음 (무조건 아님)
초기 302 스펙의 의도는 method를 유지하는 것이였으나, 웹 브라우저들이 대부분 GET으로 바꿨음
그래서 명확한 303, 307 이 등장 하였으나,이미 많은 애플리케이션 라이브러리에서 302를 기본값으로 사용하고 있음
303 (See Other)
- 302와 기능은 같음
- 리다이렉트시 요청 메서드가 GET으로 변경
307 (Temporary Redirect)
- 302와 기능은 같음
- 리다이렉트시 요청 메서드와 본문 유지 (요청 메서드를 변경하면 안된다)
PRG : Post/Redirect/Get
- 웹 개발 디자인 패턴
- POST 요청을 통해 웹 양식이 서버에 제출 될 때 서버 응답을 새로 고치려고하면 원래 POST의 내용이 다시 제출되어 중복 웹 구매와 같은 원치 않는 결과가 발생할 수 있는 사항을 방지
아래 그림처럼 주문 후, 새로고침을 하게 되면, 마지막 요청(Request)인 POST가 서버로 전송되면, 중복되는 주문이 발생할 수 있다.
하지만 다음과 같이 POST 요청 후에, Redirect 해서 GET으로 다시 서버에 요청하도록 하게 하면, 새로 고침을 눌러도 마지막 요청이 GET이기 때문에, 주문이 완료되었다는 창만 나오기 때문에 중복 주문되는 일이 없다.
특수 리다이렉션
결과 대신 캐쉬를 사용
304 (Not Modified)
- 캐시를 목적으로 사용
- 클라이언트에게 리소스가 수정되지 않았음을 알려줌.
- 클라이언트는 로컬 PC에 저장된 캐시로 리다이렉트 한다.
- 클라이언트 리소스를 사용해야되기 때문에, 바디를 포함하면 안된다.
- GET, HEAD 요청시 사용
그외 리다이렉션
300 (Multiple Choices)
사용 안함
4xx (Client Error)
클라이언트 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없을 때
클라이언트가 잘못한 것이기 때문에, 클라이언트가 요청 재시도를 해도 똑같이 실패함 (요청을 수정해야됨)
400 (Bad Request)
- 클라이언트가
잘못된 요청을 해서 서버가 요청을 처리할 수 없음 - 요청 구문, 메시지 오류
- 클라이언트는 요청 내용을 확인하고 다시 보내야됨.
401 (Unauthorized)
- 인증(Authentication - 본인 확인, 로그인) 되지 않음
- 클라이언트가 해당 리소스에 대한 인증이 필요함
- 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
- Unauthorized는 뜻 자체는 권한부여(Admin)와 더 연관된 말이기 때문에 혼동 주의
403 (Forbidden)
- 서버가 요청은 이해했지만 승인을 거부
- 주로 인증(Authentication) 자격 증명은 있지만,
접근 권한이 불충분한 경우 - ex) 일반 사용자가 관리자 리소스 접근
404 (Not Found)
- 요청 리소스를 찾을 수 없거나 (서버에 없음)
- 해당 리소스를 숨기고 싶을 때
5xx (Server Error)
- 서버 문제로 오류 발생
- 서버가 이상한 것이기 때문에, 클라이언트가 요청 재시도를 하면 성공 할 수 있다. (복구가 되서)
- 왠만해서는 5xx 에러를 만들면 안된다. 정말 서버 문제일 경우에만 (DB다운 등)
500 (Internal Server Error)
- 서버 내부 문제로 오류 발생
503 (Service Unavailable)
- 서비스 이용 불가
- 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없는 경우
- Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음
참고
