목차
HTTP 상태코드 소개
상태코드
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
•
1xx(Informational): 요청이 수신되어 처리중
•
2xx(Successful):요청 정상 처리
•
3xx(Redirection):요청을 완료하려면 추가 행동이 필요
•
4xx(Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음.
•
5xx(Server Error):서버 오류, 서버가 정상 요청을 처리하지 못함
만약 모르는 상태 코드가 나타나면?
클라이언트 입장에서 인식할 수 없는 상태 코드를 서버가 반환할 경우 클라이언트는 상위 상태코드로 해석해서 처리한다. 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다.
만약 상태코드 299 ??? 이 온다고해도 2xx이기 때문에 Successful 이라고 생각하면 된다.
다른 상태코드에 대해서는 상세히 알아보지만 1XX(Informational)은 거의 사용하지 않기 때문에 생략한다.
2xx - 성공
클라이언트의 요청을 성공적으로 처리했을때의 상태코드이다.
200 OK
가장 많이 보는 응답 메세지로 GET과 같은 조회 요청에 대해 성공적으로 요청을 받아서 결과를 잘 처리해서 응답을 할 경우 해당 상태코드를 반환한다.
201 Created
요청을 성공해서 새로운 리소스가 생성된 경우의 상태코드로 리소스 생성이니 POST요청의 성공을 한 경우에 해당한다. 그리고 이 때 응답메세지에는 생성된 리소스를 Location 헤더 필드로 식별한다.
202 Accepted
요청이 접수되었으나 처리가 완료되지 않은경우로 배치 처리 같은 곳에서 사용한다.
예를들어 요청 접수 후 1시간 뒤 배치 프로세스를 실행하라는 요청의 경우를 말한다.
204 No Content
서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없는 경우
예를들어, 웹 문서 편집기에서 저장 버튼을 눌렀을 경우 그 요청에 결과로 딱히 어떤 응답이 필요하지는 않다.
결과 내용이 없어도 204 메시지만으로 성공을 인식하기만 하면 된다.
3xx - 리다이렉션1
•
요청을 완료하기 위해 유저 에이전트(ex: 웹 브라우저) 추가 조치가 필요한 경우
•
웹 브라우저는 3xx 응답 결과에 Location 헤더가 있는 겨우 Location 위치로 자동 이동한다(리다이렉트)
자동 리다이렉트의 흐름
•
클라이언트에서 /event 를 요청.
•
서버에서는 이제 /new-event로 경로가 변경되었다고 응답
•
클라이언트에서는 자동 리다이렉트를 Location에 있는 /new-event로 수행
•
서버는 요청받은 경로인 /new-event에 대해서 정상 응답.
리다이렉션 종류(요약)
1. 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동
•
예) /members → /users
•
예) /event → /new-event
2. 일시 리다이렉션 - 일시적인 변경
•
주문 완료 후 주문 내역 화면으로 이동
•
PRG: POST/Redirect/Get
3. 특수 리다이렉션
•
결과 대신 캐시를 사용
영구 리다이렉션 301, 308
•
리소스의 URI가 영구적으로 이동
•
원래의 URL를 사용하지 않는다. 검색 엔진 등에서도 변경 인지
•
301 Moved Permanently
⇒리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다 (MAY)
•
308 Permanent Redirect
⇒ 301 과 기능은 같다
⇒ 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST로 유지)
실무에서는 경로가 바뀌면서 리다이렉션하는 경우 왠만해서는 POST사용을 유지할 필요가 없다. 페이지가 바뀌면서 필요한 파라미터나 정보들도 바뀌기 때문이다 그렇기에 대부분 308보다는 301을 사용한다. 일시적인 리다이렉션 302, 307, 303
•
리소스의 URI가 일시적으로 변경
•
따라서 검색 엔진 등에서 URL을 변경하면 안된다.
•
세가지의 기능은 모두 거의 동일하다.
•
302 Found
⇒ 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.(MAY)
•
307 Temporary Redirect
⇒ 302와 기능은 같다.
리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)
•
303 See Other
⇒ 302와 기능은 같다.
⇒ 리다이렉트시 요청 메서드가 GET으로 변경된다.
PRG: Post/Redirect/Get
일시적인 리다이렉션
만약 POST로 주문후에 웹 브라우저를 새로고침하면 어떻게 될까? 이 양식을 다시 보내겠냐며 경고창이 뜰 수 있지만, 일단 다시 요청할경우 중복으로 주문이 들어갈 수 있다.
PRG 사용 전
클라이언트에서 마우스 하나를 POST로 주문을 했고 주문완료까지된 상황에서 다시 새로고침을 하면 다시 POST로 요청이 가면서 주문이 되고 응답이 된다. 즉, 주문이 중복되는 것이다. 그럼 어떻게 해야할까?
•
POST로 주문후에 새로 고침으로 인한 중복 주문을 클라이언트에서 방지할 수 있다.
•
POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트
•
새로고침해도 결과 화면을 GET으로 조회한다.
•
중복 주문 대신 결과 화면만 GET으로 요청
PRG 사용 후
위 과정과 비슷해보이지만 최초 주문시 응답의 상태코드가 200이 아닌 302이다. 그럼 클라이언트에서는 자동 리다이렉트가 되어 GET으로 Location으로 요청을 하게되어 응답을 받고, 그 뒤로는 실수(혹은 의도적)로 새로고침을 하더라도 중복 주문이 되지 않는다.
PRG 이후 리다이렉트
•
URL 이 이미 POST → GET으로 리다이렉트 됨
•
새로고침해도 GET으로 결과 화면만 조회된다.
그럼 뭘 써야 하는가?
302, 307, 303
•
요약
⇒ 302 Found → GET으로 변할 수 있다.
⇒ 307 Temporary Redirect → 메서드가 변하면 안된다.
⇒ 303 See Other → 메서드가 GET으로 변경
•
역사
⇒ 처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것이였다. 하지만 웹 브라우저들이 대부분 GET으로 바꿔버리면서 동작이 모호해졌다. 그렇기에 모호한 302를 대신하는 307, 303이 등장했다.
•
현재
⇒ 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용.
⇒ 자동 리다이렉션시에 GET으로 변해도 되면 302를 사용해도 별 문제가 되지 않는다.
기타 리다이렉션 300, 304
•
300 Multiple Choices: 사용하지 않는다.
•
304 Not Modified
◦
캐시를 목적으로 사용한다.
◦
클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다.
◦
304 응답은 응답에 메세지 바디를 포함하면 안된다.(로컬 캐시를 사용해야 하기에)
◦
조건부 GET, HEAD 요청시 사용
4xx - 클라이언트 오류, 5xx - 서버 오류
4xx 클라이언트 오류
•
클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음.
•
오류의 원인이 클라이언트에 있을 경우.
•
클라이언트가 이미 잘못된 요청과 데이터를 보내고 있기에 재시도를 하더라도 계속 실패.
400 Bad Request
클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없는 에러
•
요청 구문, 메시지 등등에서 문제가 있을 때 발생
•
클라이언트는 요청 내용을 재검토하고 수정해서 보내야 한다.
•
서버단에서 스펙에 안맞는 요청이 오면 철저하게 검증해서 400 상태코드를 반환해서 해당 케이스에 500 에러로 서버 문제로 넘어가지 않아야 한다.
401 Unauthorized
클라이언트가 해당 리소스에 대한 인증이 필요한 경우 발생
•
인증(Authentication)되지 않음
•
401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
•
참고
◦
인증(Authentication): 본인이 누구인지 확인(로그인)
◦
인가(Authorization): 권한 부여(Admin 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있다.)
◦
오류 메세지가 Unauthorized 이지만 인증 되지 않음
403 Forbidden
서버가 요청을 이해는 했지만 승인을 거부하는 경우
•
주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
•
일반 사용자가 운영자 등급의 리소스에 접근하고자 할 때 발생
404 Not Found
요청 리소스를 찾을 수 없을때 발생
•
요청 리소스가 서버에 없음
•
또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때
5xx 서버 오류
서버에서 오류가 발생했을때 반환되는 상태 코드
•
서버 문제로 오류가 발생
•
클라이언트가 실패했을지라도 나중에 똑같은 요청을 했을때 성공할 가능성이 있다.
500 Internal Server Error
서버 문제로 오류가 발생했고, 애매한 경우 500 오류
•
서버 내부 문제로 오류가 발생
•
애매하면 모두 500 오류를 낸다.
•
중요! 정말 서버에 오류가 있을때 사용해야 한다. 비즈니스 로직상의 문제가 있거나 나이가 안되거나 잔고가 부족한 것처럼 서버가 아닌 비즈니스 조건에 문제가 되는경우 500에러를 사용해서는 안된다.
503 Service Unavailable
서비스 이용 불가
•
서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음.
•
Retry-After 헤더 필드로 얼마 뒤에 복구되는지 보낼 수 있다.
⇒ 대부분 예측 불가능한 에러기에 503에러를 보는 경우는 흔치 않다.
