HTTP 상태 코드
Last updated
Last updated
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능이다.
클라이언트는 인식할 수 없는 상태 코드를 서버로부터 받으면, 상위 상태 코드로 해석해서 처리한다. 따라서 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다.
요청이 수신되어 처리중인 상태
거의 사용하지 않는다.
클라이언트가 리소스를 달라고 요청하면 서버가 결과를 정상적으로 처리해서 응답한다.
POST는 서버에서 자원을 생성하고 URI도 관리한다. 생성된 리소스의 경로는 응답의 Location 헤더 필드로 담아 보낸다.
응답이 201이면 자원이 생성되었고 Location 헤더 필드가 있을 수 있다고 예측할 수 있다.
요청이 접수는 됐지만 처리가 완료되지 않았을 때 쓰인다. 클라이언트 요청은 성공했는데 서버는 1시간 뒤에 배치를 돌려 처리해야 할 경우 등에 쓰인다.
보통 요청에 성공하면 응답 바디에 데이터가 있는데 요청을 성공적으로 수행해도 보낼 데이터가 없을 때 쓰인다.
웹 문서 편집기에서 저장 버튼을 누르면 서버에서 저장 처리를 한 뒤 결과로 본문을 줄 필요는 없다. 그냥 잘 저장됐다는 것만 전달하면 된다. 이럴 경우 결과 내용 없이 204로 성공을 알릴 수 있다.
서버가 요청을 완료하기 위해 유저 에이전트의 추가 작업이 필요할 때 사용한다. 유저 에이전트는 주로 웹 브라우저를 말한다.
웹 브라우저가 3xx 응답 결과에 Location 헤더가 있으면 그 위치로 자동 이동하는 것을 의미한다.
이벤트가 새로운 것으로 변경되었을 때, 기존 링크가 이미 공유되었거나 즐겨찾기 되어있을 수 있으므로 새로운 경로로 가도록 리다이렉트 한다.
/members에서 /users로
/event에서 /new-event로
특정 리소스의 URI가 영구적으로 이동된다. 이전 리소스는 사용하면 안되는 상황일 때 해당된다. 검색 엔진들도 이 변경을 인지해서 새로운 URI를 적용한다.
301 Moved Permanently
리다이렉트 시 요청 메서드가 GET으로 변하고 본문이 제거될 될 수도 있다.
그럼 다시 POST로 기존의 메시지를 보내서 요청한다.
308 Permanent Redirect
301과 기능은 같다.
리다이렉트 시 요청 메서드와 본문을 유지한다.
처음 POST를 보낸 거라면 리다이렉트도 POST를 유지한다.
실무에서는 URI가 바뀌면 처리해야 할 메시지도 달라지기 때문에 POST로 와도 그냥 GET으로 돌리는 게 낫다.
주문 완료 후 주문 내역 화면으로 이동
리소스의 URI가 일시적으로 변경된다. 따라서 검색 엔진 등에서 URL을 변경하면 안된다.
302 Found
리다이렉트 시 요청 메서드가 GET으로 변하고 본문이 제거될 수도 있다.
307 Temporary Redirect
302와 기능은 같다.
리다이렉트 시 요청 메서드와 본문을 유지한다.
요청 메서드를 변경하면 안된다.
303 See Other
302와 기능은 같다.
리다이렉트 시 요청 메서드가 GET으로 변경된다.
POST로 주문을 요청하면 주문 데이터에 주문을 저장한 뒤 200을 보낸다. 만약 결과 화면에서 새로고침을 누르면 마지막 요청을 다시 보내는 행위이기 때문에 중복 주문이 발생한다.
주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트 하면 새로고침을 해도 결과 하면은 GET 조회만 발생한다. 중복 주문 대신 결과 화면만 요청하는 것이다.
클라이언트가 주문을 요청하면 응답으로 302나 303과 함께 리다이렉트할 Location을 보낸다. 그럼 클라이언트가 코드를 확인하고 302, 303이므로 GET으로 자동 리다이렉트를 한다. 새로고침을 해도 GET 결과 화면만 다시 요청한다.
그럼 302, 307, 303 중 무엇을 써야 할까?
처음 302의 의도는 HTTP 메서드를 유지하는 것이었다. 그런데 대부분의 웹 브라우저들이 GET으로 바꿔버렸고, 그래서 모호한 302 대신 명확한 307과 303이 등장했다. 307과 303을 권장하지만 현실에선 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용하고 있기 때문에 GET으로 변해도 되면 그냥 302를 사용해도 된다.
300 Multiple Choices
사용하지 않는다.
304 Not Modified
캐시를 목적으로 사용한다.
클라이언트가 캐시가 만료됐는지 서버에 확인하기 위해 캐시 정보를 넘기고, 서버는 사용해도 되면 캐시로 다시 조회하라고 응답을 보낸다.
클라이언트에게 리소스가 수정되지 않았음을 알려주면 클라이언트는 캐시로 리다이렉트 해서 로컬 PC에 저장된 캐시를 재사용 한다.
로컬 캐시를 사용해야 하므로 응답에 메시지 바디를 포함하면 안된다.
조건부 GET, HEAD 요청 시 사용한다.
클라이언트가 잘못된 요청을 해서 서버가 수행할 수 없을 때 사용한다. 클라이언트가 이미 잘못 요청한 것이기 때문에 똑같이 재시도 해도 실패한다. 5xx 에러는 재시도 하면 성공할 수 있다는 차이가 있다.
400 Bad Request
클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없는 상태
요청 파라미터가 잘못되거나 API 스펙이 맞지 않을 때 발생한다.
클라이언트가 요청 내용을 다시 검토하고 보내야 한다.
백엔드 개발자는 철저하게 validation 해서 스펙 안맞으면 바로바로 튕겨줘야 한다.
401 Unauthorized
클라이언트가 해당 리소스에 대한 인증이 필요한 상태
응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명한다.
403 Forbidden
서버가 요청을 이해했지만 승인을 거부한 상태
주로 인증 자격 증명은 있지만 접근 권한이 없을 경우에 해당한다.
로그인은 했지만 ADMIN이 아니면서 해당 리소스에 접근할 경우
404 Not Found
요청 리소스를 찾을 수 없는 상태
또는 클라이언트가 권한이 부족한 리소스에 접근하면 그 리소스를 숨기고 싶을 때 사용
인증(Authentication)
본인이 누구인지 확인하는 것
로그인
인가(Authorization)
권한을 부여하는 것
ADMIN처럼 특정 리소스에 접근할 수 있는 권한
401은 오류 메시지가 Unauthorized이지만 인증에 해당된다.
서버에 문제가 있어서 발생하는 오류다. 따라서 서버가 복구되면 재시도 시 성공할 수 있다.
500 Internal Server Error
서버 내부 문제
애매한 문제는 대부분 500 오류로 낸다.
503 Service Unavailable
서비스 이용 불가
서버가 일시적인 과부하에 걸리거나 예정된 작업으로 잠시 요청을 처리할 수 없는 상태
Retry-After 헤더 필드로 얼마 뒤에 복구되는지 보낼 수도 있다.
보통 오류는 예측 불가한 상태에서 발생하므로 500이 많이 발생한다. 서버는 웬만하면 500을 내뱉으면 안된다. 진짜 서버에 문제가 터졌을 때만 발생시켜야 한다. API 스펙도 맞고 한데 비즈니스 로직 상 실패해서 500을 내면 안된다.
잔고가 없다거나 필요한 연령 제한을 못넘겼다거나 하는 문제는 비즈니스 로직 상 정상 예외 케이스이므로 2xx, 4xx로 해결하고 DB 에러나 NPE 등의 문제에 500을 내야 한다.
