클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
1xx (informational): 요청이 수신되어 처리중
2xx (Successful): 요청 정상 처리
3xx (Redirection): 요청을 완료하려면 추가 행동 필요
4xx (Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 유청을 수행할 수 없음
5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함
인식할 수 없는 상태코드라면 상위 상태코드로 해석한다.
즉, 299 -> 2xx
1xx (Informational)
요청이 수신되어 처리 중
- 실무에서 거의 사용하지 않으므로 생략
2xx (Successful)
클라이언트의 요청을 성공적으로 처리
200 OK요청 성공201 Cretaed요청 성공해서 새로운 리소스가 생성됨202 Accepted요청이 접수되었으나 처리가 완료되지 않았음- 배치 처리 같은 곳에서 사용
- ex) 요청 접수 후 1시간 뒤에서 배치 프로세스가 요청을 처리함
204 No Content서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음- ex) 웹 문서 편집기에서 save 버튼
- save 버튼의 결과로 아무 내용이 없어도 된다.
- save 버튼을 눌러도 같은 화면을 유지해야 한다.
- 결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있다.
3xx (Redirection)
요청을 완료하기 위해 유저 에이전트의 추가 조치 필요
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
307 Temporary Redirect
308 Permanent Redirect
웹 브라우저는 3xx 응답 결과에 Location 헤거가 있으면,
Location 위치로 자동 이동 => 리다이렉트
리다이렉션 사용 예
/event 라는 옛 경로가 있고 현재는 /new-event 경로를 사용한다고 하자.
/event 경로로 접근하면 /new-event 경로로 돌려줘야 한다.
/event로 요청을 해보자.
요청 메시지
GET /event HTTP/1.1
Host: localhost:8080
응답 메시지
HTTP/1.1 301 Moved Permanently
Location: /new-eventLocation 주소로 리다이렉트가 된다.
요청 메시지
GET /new-event HTTP/1.1
Host: localhost:8080
응답 메시지
HTTP/1.1 200 OK
...- 영구 리다이렉션 - 특정 리소스 URI가 영구적으로 이동
- ex) /event -> /new-event
- 일시 리다이렉션 - 일시적인 변경
- 주문 완료 후 주문 내역 화면으로 이동- PRG: Post/Redirect/Get
- 특수 리다이렉션
- 결과 대신 캐시를 사용
영구 리다이렉션
301, 308
- 리소스 URI가 영구적으로 이동
- 원래 URL 사용X, 검색 엔진 등에서도 변경 인지
- 301 Moved Permanently
- 리다이렉트시 요청 메서드가 GET으로 변할 수 있고, 바디가 제거될 수 있음
- 308 Permanent Redirect
- 301과 기능 같음
- 리다이렉트시 요청 메서드와 바디 유지(처음 POST면 리다이렉트도 POST)
301
옛 이벤트 페이지(/event)에서 정보 입력을 하고 데이터를 전송하면
현재 이벤트 페이지(/new-event)로 리다이렉트가 되고
GET 메서드로 변하고 바디가 없어진다.
즉, 이벤트를 위해 입력한 정보가 다 사라진다.
308
301과 동일하지만
메서드가 변하지 않고 바디가 유지된다.
실무에서 이 방식은 거의 사용되지 않는다.
보통 새로운 이벤트를 위해 입력할 데이터들이 다 바뀌기 때문에
POST로 요청이 와도 GET 메서드로 돌리는 것이 맞다.
하지만 301도 거의 쓰이지 않는다.
뒤에 나올 일시적 리다이렉션이 주로 쓰인다.
일시적인 리다이렉션
302, 307, 303
- 리소스 URI가 일시적으로 변경
- 검색 엔진 등에서 URL을 변경하면 안됨
- 302 Found
- 리다이렉트시 요청 메서드가 GET으로 변할 수 있고, 바디가 제거될 수 있음 - 307 Temporary Redriect
- 302와 기능은 같음- 리다이렉트시 요청 메서드와 바디 유지 (메서드 변경하면 안된다. MUST NOT)
- 303 See Other
- 302와 기능은 같음- 리다이렉트시 요청 메서드가 GET으로 변경
302가 명확하지 않아서 307, 303를 써야할 것 같지만,
실무에서 대부분은 302를 사용하고 있다.
PRG: Post/Redirect/Get
POST로 주문 후 새로고침하면?
새로고침은 다시 요청한다.
따라서 중복 주문이 될 수 있다.
PRG 사용 전을 그리면 아래와 같다.
POST로 주문 후 새로 고침으로 인한 중복 주문 방지
POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트
새로고침해도 결과 화면을 GET으로 조회
중복 주문 대신에 결과 화면만 GET으로 다시 요청
PRG을 적용하면 아래와 같다.
그래서 무엇을 써야할까
302 Found -> GET으로 바꿀 수 있음
307 Temporary Redirect -> 메서드 바꾸면 안됨
302 See Other -> GET으로 바꿔야 함
302 의도는 HTTP 메서드를 유지하는 것이었다.
웹 브라우저 대부분이 GET으로 바꾸었다.
모호한 302 대신 명확한 307, 303 이 등장했다. (301 대응으로 308도 등장)
기타 리다이렉션
300, 304
300 Mutiple Choices: 안쓴다.
304 Not Modified
- 캐시를 목저으로 사용
- 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 클라이언트는 로컬PC에 저장된 캐시를 재사용한다. (캐시로 리다이렉트한다.)
- 304 응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 하므로)
- 조건부 GET, HEAD 요청시 사용
4xx (Client Error)
4xx error는 요청을 바뀌지 않는 이상 해결할 수 없다.
5xx error는 서버 복구가 되면 같은 요청을 성공할 수 있다.
400 Bad Request
클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
- 요청 구무느 메시지 등등 오류
- 클라이언트는 요청 내용을 다시 검토하고 보내야함
- ex) 요ㅕ청 파라미터가 잘못된거나, API 스펙이 맞지 않을 때
401 Unauthorized
클라이언트가 해당 리소스에 대한 인증이 필요함
- 인증 되지 않음
- 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
- 인증(Authentication): 누구인지 확인 (로그인)
- 인가(Aithorization): 권한 부여
403 Forbidden
서버가 요청을 이해했지만 승인을 거부함
- 주로 인증 자격 증명은 있지만, 접근 권힌이 불충분한 경우
- ex) 어드민 등급이 아닌 사용자가 로그인은 했지만, 어드민 등급의 리소스에 접근하는 경우
404 Not Found
요청 리소스를 찾을 수 없음
- 요청 리소스가 서버에 없음
- 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때
5xx
500 Internal Server Error
서버 문제, 애매하면 500 오류
503 Service Unavailable
서비스 이용 불가
- 일시적 과부하 또는 예정된 작업으로 잠시 요청 처리를 할 수 없음
- Retry-After 헤더 필드로 얼마 뒤에 복귀되는지 보낼 수도 있음
유저가 20살 이상이여서 주문할 수 있는 상품을 주문했을 때
500 에러를 내면 안된다.
500 에러는 진짜 서버에 문제가 있을 때 발생해야 한다.
References
https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard
