👩💻 HTTP 상태코드
📌 HTTP 상태코드 소개
✏️상태코드
: 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
- 1xx(Informational): 요청이 수신되어 처리중 (거의 사용 되지 않음)
- 2xx (Successful): 요청 정상 처리
- 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요함
- 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
- 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 (데이터 베이스 오류등)
"만약에 모르는 상태 코드가 나타나면 ?"
: 클라이언트는 상위 상태코드로 해석해서 처리
✏️ 2xx - 성공 (1xx대는 잘 사용하지 않으므로 넘어가도록 한다)
: 클라이언트 요청을 성공적으로 처리
- 200 OK
클라이언트가 GET으로 /members/100번 리소스 주라고 요청하면 서버에서 결과를 정상적으로 처리해서 응답함
-> 성공 시 200 OK
- 201 Created (클라이언트가 요청한 것을 서버 쪽에서 리소스를 생성함)
- 202 Accepted (요청이 접수되었으나 처리가 완료되지 않았음)
- 배치 처리 같은 곳에서 사용 (요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리하는 등의 경우)
- 잘 사용 안함
- 204 No Content (서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
- 웹 문서 편집기에서 save 버튼
- save 버튼의 결과로 아무 내용이 없어도 된다.
- save 버튼을 눌러도 같은 화면을 유지해야 한다. (워드 작성할때 save 눌러도 화면변화가 없는것처럼)
- 결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있다.
✏️ 3xx - 리다이렉션 (요청을 완료하려면 추가 행동이 필요함)
: 클라이언트 요청을 완료하기 위해 추가적인 조치가 필요하여 다시 클라이언트에게 보냄
- 300 Multiple Choices
- 301 Moved Permanently
- 302 Found
- 303 See Other
- 304 Not Modified
- 307 Temporary Redirect
- 308 Permanent Redirect
1. "리다이렉션의 이해"
:웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)
옛날에 event 페이지를 뿌리다가 더 이상 /event를 쓰지않고 새로운 이벤트인 /new - event 경로를 쓰기로 결정하였다.
기존 사용자들은 옛날 event 페이지를 북마크 해둘 수 도 있고, 기존의 링크가 여러군데에 링크가 공유되어있을수있다.
그럴 때 요청으로 /event로 웹브라우저에서 치고 들어오면 서버입장에서 이 경로는 완전히 안 쓰고 new event로 바뀌었다고 2. 응답으로 알려준다.
그럼 클라이언트 웹브라우저가 스스로 URL 창의 경로를 new_event로 바꾸어 요청한다.
2. "리다이렉션의 종류"
- 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동
- 예) /event -> /new-event
- 예) /members -> /users
- 일시 리다이렉션 - 일시적인 변경
- 주문 완료 후 주문 내역 화면으로 이동
- PRG: Post/Redirect/Get
- 특수 리다이렉션
- 결과 대신 캐시를 사용
3. 3xx - 리다이렉션
- 영구 리다이렉션 - 301, 308
- 리소스의 URI가 영구적으로 이동
- 원래의 URL을 사용X, 검색 엔진 등에서도 변경 인지
- 301 Moved Permanently
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
- 308 Permanent Redirect
- 301과 기능은 같음
- 리다이렉트시 요청 메서드와 본문 유지
영구 리다이렉션 - 301
POST를 사용하여 내부에 html Form에 데이터를 작성하여 전송한다.
하지만 서버는 event를 사용하지 않고 /new-event를 사용한다고 응답하고, 클라이언트는 자동 리다이렉트를 하여 new-event를 "GET"으로 변경하여 요청한다. 그러면 서버는 뉴 이벤트 페이지를 보여달라고 하는거구나. 라고 생각하여 다시 new-event 페이지를 보내준다.
영구 리다이렉션 - 308
308로 보내면 다 똑같은데 "POST"를 유지하여 서버로 보내준다.
- 일시적인 리다이렉션 - 302, 307, 303
- 리소스의 URI가 일시적으로 변경
- 따라서 검색 엔진 등으로 URL을 변경하면 안됨
- 302 Found
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
- 307 Temporary Redirect
- 302와 기능은 같음
- 리다이렉트시 요청 메서드와 본문 유지. 요청 메서드를 변경하면 안된다. (Must Not)
- 303 See Other
- 302와 기능은 같음
- 리다이렉트시 요청 메서드가 GET으로 변경(확정)
5. PRG: Post/Redirect/Get
:일시적인 리다이렉션 - 예시
- POST로 주문후에 웹 브라우저를 새로고침하면?
- 새로고침은 다시 요청하기 때문에 중복 주문이 될 수 있다.
"PRG: 사용 전"
"PRG: 사용 후"
마우스와 카운트 값을 지정하여 요청하면 서버에서 주문데이터를 저장한 뒤 응답하는데, 응답을 200 OK를 주는게 아니라 302 Found를 준다. 그러면 로케이션 정보를 클라이언트에 주게된다 (Location: /order-result/19)
그럼 사용자가 300 시리즈의 리다이렉트가 왔으니 리다이렉트를 해준다.
그때 302면 POST를 GET으로 바꾸고, 주문 데이터를 쌓는것이 아니라 주문데이터를 조회하고 html 화면을 만들어 200 OK를 보낸다.
이렇게 된다면 사용자가 새로고침을 해도 중복 주문이 들어가는 것이 아닌 5번~6번이 반복되게 된다.
"정리" - 그래서 무엇을 써야 하나요?
[정리]
- 302 Found -> Get으로 변할 수 있음 *대부분 변함*
- 307 Temporary Redirect -> 메서드가 변하면 안됨
- 303 See Other -> 메서드가 Get으로 변함
[역사]
- 처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것 이였음
- 하지만 웹 브라우저들이 대부분 GET으로 바꾸어버림
- 그래서 모호한 302를 대신하는 명확한 307, 303이 등장
[현실]
- 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이셔 라이브러리들이 302를 기본값으로 사용
- 자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제 없음
✏️ 4xx - 클라이언트 오류
: 클라이언트 오류
- 클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음
- 오류의 원인이 클라이언트에 있음
- 중요 ! 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패함.
- 400 Bad Request
- 말 그대로 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
- 요청 구문, 메시지 등등 오류 (클라이언트는 요청 내용을 다시 검토하고, 보내야함)
- ex) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때
- 401 Unauthorized
- 클라이언트가 해당 리소스에 대한 인증이 필요함
- 인증(Authentication)되지 않음. 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
- 403 Forbidden
- 서버가 요청을 이해했지만 승인을 거부함
- 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우 (로그인은 했지만 접근 권한이 없을 때)
- 404 Not Found
- 요청 리소스를 찾을 수 없음
- 요청 리소스가 서버에 없거나 또한 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때
✏️ 5xx - 서버 오류
: 서버 오류
- 서버 문제로 오류 발생
- 서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음
- 500 Internal Server Error
- 서버 내부 문제로 오류 발생
- 애매하면 500 오류로 내면 됨
- 503 Service Unavailable
- 서비스 이용 불가
- 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
'CS > HTTP' 카테고리의 다른 글
[HTTP] 모든 개발자를 위한 HTTP 웹 기본 지식 - 8 (0) | 2024.01.04 |
---|---|
[HTTP] 모든 개발자를 위한 HTTP 웹 기본 지식 - 7 (0) | 2024.01.03 |
[HTTP]모든 개발자를 위한 HTTP 웹 기본 지식 - 5 (0) | 2024.01.03 |
[HTTP]모든 개발자를 위한 HTTP 웹 기본 지식 - 4 (0) | 2023.12.28 |
[HTTP]모든 개발자를 위한 HTTP 웹 기본 지식 - 3 (0) | 2023.12.26 |