
이 포스팅은 인프런 김영한 강사님의 <모든 개발자를 위한 HTTP 웹 기본 지식>을 수강하고, 공부하여 글로 정리한 것입니다. 그대로 갖다 붙여넣는 내용이 아니라 기억나는대로 작성한 후 다시 추가적으로 정리하는 방식을 취하고 있기 때문에 틀린 부분이 있을 수 있습니다. 잘못된 점은 짚어주시면 감사하겠습니다.
클라이언트가 보낸 요청의 처리상태를 응답에서 알려주는 기능.
클라이언트가 인식할 수 없는 상태코드가 나타나면 상태코드 앞자리로 해석하여 처리한다. 새로운 상태코드가 추가되어도 클라이언트 변경할 필요가 없어짐.
요청 성공.
요청 성공하여 새로운 리소스 생성됨.
새로운 리소스는 응답 메시지에 Location 헤더 필드로 식별한다.
요청이 접수됐지만 처리 완료되지 않음.
배치 처리 등에 사용된다.
요청 성공적으로 수행됐지만, 요청 페이로드 본문에 보낼 데이터가 없음.
결과 내용이 없어도 204 상태코드만으로 성공 여부 인식.
예) 웹 문서 편집기의 save 버튼. 버튼 눌러도 같은 화면 유지됨.
요청 완료하기 위해 유저 에이전트(주로 웹브라우저)의 추가 조치가 필요한 경우.
3xx 응답 결과에 Location 헤더가 있으면, 해당 위치로 자동으로 이동한다.(=리다이렉트)

특정 리소스 URI가 영구적으로 이동. 원래 URL을 사용하지 않고, 검색엔진 등도 변경을 인지한다.
301 : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음.(MAY)
308 : 301과 기능은 같지만, 리다이렉트시 요청 메서드와 본문은 유지됨.
리소스 URI의 일시적 변경. 검색엔진 등에서 URL 변경하면 안됨.
302 Found : 리다이렉트시 요청 메서드가 GET으로 변경되고, 본문이 제거될 수 있음.(MAY)
307 Temporary Redirect : 리다이렉트시 요청 메서드가 변경되면 안됨. 본문도 유지.(MUST NOT)
303 See Other : 리다이렉트시 요청 메서드가 GET으로 변경됨.
일시적 리다이렉션은 언제 사용될까?
PRG(Post Redirect Get)
- 예) POST 주문 후 새로고침할 경우, 주문이 다시 요청되어 중복처리될 수 있음.
- 중복 주문을 방지하기 위해 POST 주문 후 주문결과 화면을 GET으로 리다이렉트 해준다.
300 Multiple Choices : 사용 X
304 Not Modified : 캐시 목적 사용.
- 클라이언트에게 리소스가 수정되지 않았다고 알려주면, 클라이언트는 로컬 PC에 저장된 캐시를 재사용함.(캐시로 리다이렉트)
- 응답에 메시지 바디 포함하면 안된다. 왜? 로컬 캐시 사용해야 하기 때문.
- 조건부 GET, HEAD 요청시 사용.
클라이언트의 잘못된 요청으로 서버가 요청을 수행할 수 없는 경우.
오류의 원인은 클라이언트에게 있기 때문에, 여러번 재시도해도 성공할 가능성 없음.
400 Bad Request : 클라이언트가 잘못 요청하여 서버가 요청 처리 불가. 클라이언트에서 요청 재검토하고 보내야 함.
401 Unauthorize : 클라이언트가 해당 리소스에 대한 인증이 필요. 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명해주어야 함.
403 Forbidden : 서버가 요청 이해했지만 승인을 거부. 주로 인증 자격증명은 있지만, 해당 리소스에 접근 권한이 불충분한 경우. (일반 사용자가 관리자 권한이 필요한 리소스에 접근하는 경우)
404 Not Found : 요청 리소스를 찾을 수 없거나, 403과 같은 경우에 해당 리소스를 숨기고 싶을 때 사용.
서버 문제로 오류가 발생한 경우. 서버 문제이기 때문에 재시도하면 성공할 가능성이 있음.
500 Internal Server Error : 서버 내부 문제로 발생. 애매하면 대부분 500 오류.
503 Service Unavailable : 서버의 일시적 과부하나 예정된 작업 요청을 잠시 처리할 수 없는 경우. Retry-After 헤더 필드로 얼마 뒤에 복귀되는지 보낼 수 있음.