상태 코드란?
클라이언트가 보낸 요청의 처리 상태를 읍답에서 알려주는 기능
- 1xx (Informational): 요청이 수신되어 처리중 (거의 사용 안함)
- 2xx (Successful): 요청 정상 처리
- 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
- 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청할 수 없음
- 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함
3xx - 리다이렉션
- 300 Multiple Choices
- 301 Moved Permanently
- 302 Found
- 303 See Other
- 304 Not Modified
- 307 Temporary Redirect
- 308 Permanent Redirect
일시적인 리다이렉션 (302, 303, 307) -실무에서 많이 사용
- 리소스의 URI가 일시적으로 변경되어 검색 엔진 등에서 URL을 변경하면 안된다.
- 302 Found
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.(MAY)
- 303 See Other
- 302와 기능은 같고 리다이렉트시 요청 메서드가 GET으로 변경
(302가 명확하지 않아서 GET으로 보내고 싶을 때 사용한다.)
- 302와 기능은 같고 리다이렉트시 요청 메서드가 GET으로 변경
- 307 Temporary Redirect
- 302와 기능은 같고 리다이렉트시 요청 메서드와 본문이 유지된다.
(요청 메서드를 변경하면 안된다.(MUST NOT))
- 302와 기능은 같고 리다이렉트시 요청 메서드와 본문이 유지된다.
302 Found -> GET으로 변할 수 있다.
303 See Other -> GET으로 변경
307 Temporary Redirect -> 메서드가 변하지 않고 유지
-역사-
처음 302 스펙의 의도는 HTTP 메서드를 유지하는 거였는데 웹 브라우저들이 대부분 GET으로 바꾸어 버리면서
일부는 다르게 동작하게 되어 버렸다. 그래서 명확한 307, 303이 등장하게 되었다.(301 대응으로 308도 등장)
-현실-
307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용한다.
자동 리다이렉션시 GET으로 변해도 되면 302를 사용해도 큰 문제 없다.
PRG: Post/Redirect/Get
일시적인 리다이렉션 -Ex
POST로 주문 한 상태에서 웹 브라우저를 새로고침 한다면?
(방금 POST로 보낸 데이터가 한번 더 들어가게 된다. -중복 주문)
- POST로 주문후에 새로 고침으로 인한 중복 주문 방지
(클라이언트에서 방지하는게 사용자 사용성에서 좋다.) + 서버- POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트
(주문 한 결과화면으로 GET 메서드로 Redirect 해주기 -> 새로고침 해도 GET)- 중복 주문 대신에 결과 화면만 GET으로 다시 요청
PRG사용전
- 요청 (URL: /orders) -> POST
POST/orders HTTP/1.1
Host: localhost:8080
itemId=mouse&count=1- 주문데이터 저장
1. 요청으로 인해 mouse 1개가 DB에 저장된다.- 응답
HTTP/1.1 200 OK
<html>주문완료</html>- 결과 화면에서 새로고침 (URL: /orders) -> 마지막 요청을 새로고침
주문완료가 띄어진 정적페이지에서 새로 고침으로 인해
요청이 들어가 버린다.- 요청
POST/orders HTTP/1.1
Host: localhost:8080
itemId=mouse&count=1- 주문데이터 저장
5. 요청으로 인해 mouse 1개가 DB에 저장된다. // 문제점- 응답
HTTP/1.1 200 OK
<html>주문완료</html>이런 문제들은 서버에서 잘 막아야 된다. 어떻게 막아도 들어올 수 있지만
중복 주문이 들어오면
-잘못된 상품 주문번호 입니다-, -이미 사용된 주문 번호입니다.-
이런식으로 데이터를 버리거나해서 막아야 된다. (클라이언트에서도 하나 막아주는게 좋다.)
PRG사용후
- 요청 (URL: /orders) -> POST
POST/orders HTTP/1.1
Host: localhost:8080
itemId=mouse&count=1- 주문데이터 저장
1. 요청으로 인해 mouse 1개가 DB에 저장된다.- 응답 -PRG 적용
HTTP/1.1 302 Found
Location: /orders-result/19- 자동 리다이렉트
URL: /orders -> URL: /orders-result/19- 요청 -> GET으로 바뀐다. (302 Found)
GET /orders-result/19 HTTP/1.1
Host: localhost:8080- 주문데이터 조회 19번 주문
19번 주문을 DB에서 조회하고 html 뿌린다.- 응답
HTTP/1.1 200 OK
<html>주문완료</html>이후 새로고침을 해도 마지막으로 한 요청이 들어가기 때문에
GET으로 요청되고 DB에서 19번 주문을 조회하고 주문완료 html 뿌리는걸 반복하게 된다.
(5번으로 다시 이동이라고 생각하기)
302 Found 말고 -> 303 See Other 사용해도 된다.
기타 리다이렉션 (300, 304)
- 300 Multiple Choices -> 사용하지 않는다.
- 304 Not Modified
- 캐시를 목적으로 사용한다.
- 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC애
저장된 캐시를 재사용한다. (캐시로 리다이렉트)클라이언트에서 서버로 큰 이미지가 있는데 캐시가 만료된거 같아서 서버한테 다시 내려달라고 요청을 보냈더니 서버에서 그대로 사용해도 된다고 응답이 왔다. 데이터 안줄테니까 클라이언트에서 직접 캐시에 있는걸로 쓰라고 하면 이미지를 보낼 필요가 없어지기 때문에 네트워크 다운로드 용량이 줄어든다. - 304 응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 되기 때문에)
- 조건부 GET, HEAD 요청시 사용한다.
4xx vs 5xx -> 오류 고민? -> 누구 잘못이야?
4xx - 클라이언트 오류
- 클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없다. (오류의 원인이 클라이언트에 있다.)
중요! 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같이 재시도 해도 실패함
(클라이언트에서 똑같이 요청을 보낼 때 4xx대 오류는 복구 불가능 클라이언트 요청을 수정해서 보내야 된다. 클라이언트가 똑같이 요청을 보내도 5xx대 오류는 서버 쪽 오류를 잡고 재요청시 요청이 될 수 있다. )
400 Bad Request
- 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없다.
- 요청 구문, 메시지 등등의 오류
- 클라이언트는 요청 내용을 다시 검토하고 보내야 된다.
- Ex) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때 발생
- 스펙이 안 맞으면 서버 쪽에서 미리 팅겨내야 된다. 400오류로 500으로 팅기면 안된다.
(클라이언트 쪽에서 서버쪽에서 발생한 오류로 생각할 수 있다.)
- 스펙이 안 맞으면 서버 쪽에서 미리 팅겨내야 된다. 400오류로 500으로 팅기면 안된다.
401 Unauthorized
- 클라이언트가 해당 리소스에 대한 인증이 필요하다.
- 인증(Authentication) 되지 않을 때
- 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명해주기
참고
- 인증(Authentication): 본인이 누구인지 확인 (로그인)
인가(Authorization): 권한부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한,
인증이 있어야 인가가 있다.)
- 오류 메시지가 Unauthorized 이지만 인증 되지 않음
403 Forbidden
- 서버가 요청을 이해했지만 승인을 거부할 때 사용
- 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
- 예) 어드민 등급이 아닌 사용자가 로그인은 했지만, 어드민 등급의 리소스에 접근하는 경우
404 Not Found
- 요청 리소스를 찾을 수 없을 때
- 요청 리소스가 서버에 없다.
- 클라이언트가 권한이 부족한 리소스에 접근할 때
-> 403 말고 해당 리소스를 숨기고 싶을 때
5xx - 서버 오류
- 서버 문제로 오류 발생
- 서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있다(복구될 수 있다.)
(NPE나 DB접근 불가능등)
500 Internal Server Error
- 서버 문제로 오류 발생, 애매하면 500 오류
- 서버 내부 문제로 오류 발생 + 애매하면 500 오류 던지기
503 Service Unavailable
- 서비스 이용 불가
- 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없다.(1시간 정도 server down 시킬 때)
- Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있다.
500대 오류는 진짜 서버 터졌을 때만 사용하자!!
'Web' 카테고리의 다른 글
| OAuth2(Open Authorization) (0) | 2023.04.08 |
|---|---|
| Redis(Remote Dictionary Server) (0) | 2023.03.30 |
| JWT(Json Web Token) (0) | 2023.03.23 |
| HTTP 메소드 (0) | 2022.12.29 |
| 상태 코드(1) (0) | 2022.12.29 |
