상태코드: client가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
종류
1xx (Informational): 요청이 수신되어 처리중
2xx (Successful): 요청 정상 처리
3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함
1. 2xx (Successful)
200 OK
요청 성공
201 Created
요청 성공해서 새로운 리소스가 생성됨
202 Accepted
요청이 접수되었으나 처리가 완료되지 않았음
배치 처리
- 대량의 반복적인 데이터 작업을 완료하는 데 사용하는 방법
- 시스템에서 주문을 그때그때 처리하는 대신 하루가 끝날 때 모든 주문을 수집하고 주문 처리 팀과 하나의 배치로 공유
204 No Content
서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
- 웹 문서 편집기의 save 버튼
2. 3xx 리다이렉션
리다이렉션
의미: 다시 지시
용어: 리다이렉션과 리다이렉트가 있다.
정리(개념): 요청을 했을 때 3xx로 다시 요청을 보내게 하는 전체 과정이 리다이렉션(총 2번의 요청을 보낸다. 이때 method가 변경이 되고 말고는 3xx가 결정)이고, 처음 응답에서 header에 'Location: uri' 존재시 그 uri로 이동하는 것을 리다이렉트 라고 한다. (location이 없으면 동일한 uri 페이지에서 재응답을 한다.)
리다이렉션
요청(1) -> 응답(3xx) - 내가 보낸 정보에 맞게 (새 URI로 이동 혹은 동일 URI에서),(동일 method 혹은 GET method로) 다시 요청하세요 -> 요청(2) - > 응답(2xx)
종류
영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동
301, 308
일시 라다이렉션 - 일시적인 변경
302, 303, 307 - PRG
특수 리다이렉션 - 결과 대신 캐시 사용
정리(종류)
영구 리다이렉션은 내가 요청한 페이지가 다른 uri로 아예 이사를 가서 그쪽으로 가야지만 내가 원하는 요청을 할 수 있을때, 말그대로 아예 이동을 해서 그 곳에서 작업을 해야되는 경우 사용하는 리다이렉션.
ex) 내 회사가 부산(원래 uri)에 있어서 부산에 가서 일(http method)하려고 했는데 건물 안내문(3xx 상태 메시지)에 서울(Location)로 이동했다고 한다. 그러면 서울로 우선 이동(리다이렉트)을 하고 일을 할지 말지 결정(3xx에 따라 달라짐)을 할 것이다.
일시적 라다이렉션은 크게 2가지 경우 존재.
1) 내가 요청한 uri가 이사는 가지 않았다. 하지만 일시적인 오류로 접속이 되지 않을 때 다시 요청을 보낼 수 있도록 3xx를 client한테 보내서 요청을 다시 보내도록 하는 것. (302,302,308)
2) 내가 요청한 link/동작이 완료될 때(= 쿠팡 주문접수), redirection을 통해서 마지막 동작 상태를 post를 get으로 변경함 -> 중복주문 방지
* 이런 요청은 서버로 데이터를 전달해야 하므로 post method 사용. (302,303)
301 Moved Permanently
308 Permanent Redirect
302 Found
303 See Other
307 Temporary Redirect
300 Multiple Choices
304 Not Modified
영구 리다이렉션 (301, 308)
301: POST -> GET, 메시지 제거(=본문 제거)
308: POST -> POST, 메시지 유지(=본문 유지), 거의 사용X
ex) 내가 로그인 하려는 페이지가 변경이 되었다. 그래서 리다이렉션 응답을 받고 새로운 로그인 페이지로 갔는데 301을 다시 아이디 비번 쳐야되고 308은 다시 칠 필요가 없다.
일시적 리다이렉션(302,303,307) 303,307은 302 새 버전일 뿐이다.
302 Found - 거의 POST -> GET
• 리다이렉트시 요청 메서드가 GET으로 변하고, 본문(=http 메시지)이 제거될 수 있음(MAY)
303 See Other - POST -> GET
• 302와 기능은 같음
• 리다이렉트시 요청 메서드가 GET으로 변경
307 Temporary Redirect - POST -> POST
• 302와 기능은 같음
• 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)
PRG(post,redirection,get) - 302,303
주문하는 button을 클릭할 때 PRG가 적용이 되지 않으면,
POST로 요청 하고 200 응답(+ 같은 URI에 html로만 주문 완료페이지로 변경)을 받는다.
이때 화면을 새로고침하게 되면 직전 요청을 반복하게 된다.
그래서 POST 요청을 한 번 더하게 된다. = 중복주문 문제가 생김
문제 해결: PRG라고 하는 일시적 리다이렉션을 사용
주문 button을 클릭하고 POST로 요청 (여기까지 동일)
302 응답(새 Location 이동)하고 GET으로 리다이렉트
직전 요청이 GET이고 새 URI로 이동을 하였으므로 새로고침시 GET으로 조회만 가능
중복주문 문제 해결. (물론 server 쪽에서도 중복주문 막는 코드 작성 필요)
307
내가 요청한 uri가 이사는 가지 않았지만 일시적인 오류로 접속이 되지 않을 때 다시 요청을 보낼 수 있도록 3xx를 client한테 보내서 요청을 다시 보내도록 하는 것. (302,303, 307) 다 사용 가능한데,
만약 동작/링크 작동을 해줘야 할 때는 method를 유지하는 307을 사용한다.
기타 리다이렉션(300, 304)
300: 안씀
304
캐시를 목적으로 사용
client에게 리소스(요청한 페이지의 정보)가 수정되지 않았음을 알려줘서 로컬PC에 저장된 캐시를 재사용해서 redirect
로컬 캐시를 사용해야 하므로 304응답에 메시지 바디가 포함되면 안된다.
3. 4xx 클라이언트 오류
오류 원인이 client 한테 있음. - 같은 요청시(재시도시) 항상 실패
400
client가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
ex) 요청 params나 API 스펙이 맞지 않을 때
401
client가 해당 리소스에 대한 인증이 필요 - WWW-Authenticate 헤더와 함께 인증 방법을 설명
403
요청이 다 정확하지만 승인 거부당함 - admin 등급이 아닌 사용자가 admin 등급의 리소스에 접근하는 경우
404
요청 리소스가 서버에 없음, 혹은 403으로 쓰기 싫을때 무지성으로 사용
4. 5xx 서버 오류
서버 문제로 오류 - 재시도 하면 성공 할수 있음(서버가 복구가 될때)
500
서버 내부 문제로 오류 발생 - 애매하면 다 500 오류로 작성
503
서비스 이용 불가 - 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청 처리 불가(새학기 수강신청)
Retry-After 헤더 필드로 복구에 걸리는 시간 보낼 수 있음 - 장담 못하니깐 잘 안씀
이전 발행글: 5. HTTP 메서드 활용
다음 발행글: 7. HTTP 헤더 개요
출처: Inflearn-모든 개발자를 위한 HTTP 웹 기본 지식