[인강노트-웹지식] 5. HTTP 상태 코드

봄도둑·2022년 5월 17일

김영한_모든 개발자를 위한 HTTP 웹 기본 지식

목록 보기

5/7

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의 내용을 정리한 노트입니다. 블로그에 있는 자료를 사용하실 때에는 꼭 김영한님 강의 링크를 남겨주세요!

클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 역할
종류
- 1xx(informational) : 요청 처리중(잘 안쓰임)
- 2xx(successful) : 요청 정상 처리 ex) 200 ok
- 3xx(redirection) : 요청을 완료하려면 추가 행동이 필요
- 4xx(client error) : 클라이어언트의 오류 → 잘못된 요청 등으로 서버가 요청을 수행할 수 없음
- 5xx(server error) : 서버 오류 → 서버가 정상 요청을 처리 하지 못함
모르는 상태 코드가 나오면 상위 상태 코드로 해석해서 처리
- 앞자리의 상태코드로 이해해서 처리하면 됨 → 나중에 새로운 상태 코드가 추가 되어도 클라이언트를 변경하지 않아도 됨
- 4052 → 4xx 클라이언트 오류로 받아들이면 됨

200 ok
- 결과를 잘 줄 때
201 created
- 요청에 성공해서 새로운 리소스가 생성됨
- 생성된 리소스는 응답의 location 헤더 필드로 식별
202 accepted
- 요청이 접수되었으나 처리가 완료되지 않았음
- 배치 처리에서 주로 사용 → 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리할 때
204 not content
- 서버의 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
- save 버튼 → save 버튼을 누르면 같은 화면이 유지되어야 함 + save 버튼을 누른 결과로 아무 응답이 없어도 무방함

요청을 완료하기 위해 유저 에이전트(웹 브라우저)의 추가 조치 필요
301 ~ 308이 주로 사용됨
웹 브라우저는 3xx 응답의 결과에 location 헤더가 있으면 해당 location의 위치로 자동 이동(리다이렉트)
리다이렉션의 종류
- 영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동 ex) /event → /newEvent
- 일시 리다이렉션 : 일시적인 변경 ex) 주문 완료 후 새로고침 시 주문 내역 화면으로 이동
- 특수 리다이렉션 : 결과 대신 캐시 사용 ex) 캐시 만료 여부 체크

리소스의 URI가 영구적으로 이동
원래의 URL을 사용하지 않음 → 검색 엔진 등에서도 변경 인지
301
- 리다이렉트 시 요청 메소드가 GET으로 변하고 본문이 제거될 수 있음 → 클라이언트에서 url 리다이렉트를 하고 GET과 메시지(body)가 제거된 상태로 서버에 요청
308
- POST로 최초 전송 시 POST 메소드를 유지하면서 본문(body)도 같이 유지
- 전체적인 흐름으로는 301과 동일한 기능
- 그런데 url이 바뀌는 경우는 받아야할 데이터도 완전히 바뀌는 경우가 많기 때문에 301(GET)으로 리다이렉트 해주는 것이 좋음 → 308은 실무에서 자주 쓰이지는 않음

리소스의 URI가 일시적으로 변경 → 검색 엔진등에서 URL을 바꾸면 안됨
실무에서는 영구 리다이렉션보다 일시적인 리다이렉션을 더 많이 씀 → 사용성도 좋고 서버의 오류 처리에 용이하기 때문
302 : 301과 유사(영구냐 일시냐의 차이)
307 : 308과 유사(마찬가지로 영구냐 일시냐의 차이)
303 : 리다이렉트 시 요청 메소드가 GET으로 변경
예시
- PRG : Post/Redirect/Get
- POST로 주문 후 웹 브라우저를 새로고침하면 → 리다이렉트가 없다면 주문이 또 들어감 → 중복 주문이 발생할 가능성이 있음
- POST로 주문 후에 새로 고침으로 인한 중복 주문 방지 → POST로 주문 후 주문 결과 화면을 GET 메소드로 리다이렉트 → 새로고침을 해도 결과 화면을 GET으로 조회
307, 303 을 권장하지만 현실적으로 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용하고 있음 → 자동 리다이렉션 시 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제가 없음

300 : 안씀
304 not modified
- 캐시를 목적으로 사용
- 클라이언트의 리소스가 수정되지 않았음을 알려줌
- 서버가 클라이언트에게 로컬 PC에 저장된 캐시를 사용하라고 알려줌 → 캐시를 리다이렉트해서 로컬 캐시를 쓰도록 해야 하기 때문에 304 응답에 메시지 바디를 포함하면 안됨

클라이언트의 요청이 잘못되어 서버가 요청을 수행할 수 없음
오류의 원인이 클라이언트에 있음
클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 똑같은 재시도는 항상 실패함
400 bad request
- 클라이언트의 잘못된 요청으로 서버가 요청을 처리할 수 없음
- 클라이언트는 요청 내용을 다시 검토하고 보내야함
- 요청 파라미터가 잘못 되었거나 API 스펙에 맞지 않을 때
401 Unauthorized
- 클라이언트가 해당 리소스에 대한 인증이 필요함
- 인증(Authentication) 되지 않음 → 401 오류 발생 시 WWW-Authenticate 헤더와 함께 인증 방법을 설명
- 인증(Authentication) : 님 누구? (로그인)
- 인가(Authorization) : 누군지는 알겠는데 뭘 할 수 있음? → 리소스에 대한 접근 권한(로그인을 해야 인가를 받을 수 있음)
403 Forbbidden
- 서버가 요청을 이해했지만 승인을 거부함
- 인증 성공 but 접근 권한이 불충분함
- ex) 일반 사용자가 어드민 리소스에 접근할 때
404 Not found
- 요청 리소스를 찾을 수 없음
- 또는 클라이언트가 권한이 부족한 리소스에 접근 시 해당 리소스를 숨기고 싶을 때(403 대신 사용)

서버에 문제가 터졌을 때 500 에러를 만들어야 함
비즈니스 로직상 API 스펙에 맞게 다 들어왔을 때 서버에서 500 에러가 발생하면 안됨
진짜 진짜 진짜 서버에 문제가 있을 때만 클라이언트에 500 에러를 응답해야 함!!!!!!! → 서버 개발자는 이러한 부분을 철저히 분류해서 500에러인지 아닌지를 구분해서 전달할 수 있도록 해야함