HTTP 상태코드란, 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능이다.
종류는 아래와 같다.
1XX(Informational) : 요청이 수신되어 처리중
2XX(Succesful) : 요청 정상처리
200 OK
201 Created -> 요청 성공해서 새로운 리소스가 생성됨
202 Accepted - > 요청이 접수되었으나 처리가 완료되지 않음 (예를 들어 요청 접수되고 1시간 뒤에 작업이 수행될때)
204 No Content -> 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없을때(예컨대 웹 문서 편집기에서 save버튼 눌렀을때 같은 화면을 유지해야하기 때문에 결과로 아무 내용도 없어야한다. )
3XX(Redirection):요청을 완료하려면 유저 에이전트(ex) 클라이언트인 웹 브라우저) 의 추가 조치 필요
1.
요청 - GET /event HTTP/1.1
Host:localhost:8080
2.
응답- HTTP/1.1 301 Moved Permanently
Location:/ new-event
3. 자동 리다이렉트
4. 요청- GET/new-event HTTP/1.1
HOST: localhost:8080
5. 응답 HTTP/1.1 200 OK
예를 들어 GET /event로 요청하여 지금은 종료된 구 이벤트 링크를 띄우려고 할 때
서버가 현재 진행하는 /new-event로 리다이렉트 해 줄 수 있음
리다이렉션도 종류가 있다.
1. 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동
ex) /members -> /users
/event -> /new-event
2. 일시 리다이렉션 - 일시적인 변경이 필요할때 씀
ex) 주문 완료 후 주문 내역 화면으로 이동
PRG: Post/Redirect/Get
3. 특수 리다이렉션
결과 대신 캐시를 이용한다.
영구 리다이렉션( 301, 308)
- 리소스의 URI가 영구적으로 이동
- 원래의 URL을 사용X, 검색 엔진등에서도 변경 인지
- 301 Moved Permanently
리 다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수도 있음(MAY)
예를 들어 이벤트 등록하는 상황을 생각해보자.
1. 요청 POST /event HTTP/1.1
Host: localhost:8080
name=hello&age=20
-> 클라이언트가 구 이벤트 페이지에서 name과 age를 입력하고 post요청을 날려준 상황
2. 응답 HTTP/1.1 301 Moved Permanently
Location: /new-event
-> 으응 아냐아냐 이제 그런 링크 없어 /new-event로 옮겨줄게
3. 자동 리다이렉트, GET으로 변경
4. 요청 GET/new-event HTTP/1.1
Host:localhost:8080
-> get으로 변하고 본문이 제거 되었다.
-> 새로운 이벤트 페이지의 폼이 나오거나 새로운 페이지의 화면이 나오게 됨.
5. 응답 HTTP/1.1 200 OK
->이러한 상황을 해결한게 308
- 308 Permanent Redirect
301과 기능은 같지만 리 다이렉트시 요청 메서드와 똑같이 본문을 유지하는 특징을 지닌다.
1. 요청 POST /event HTTP/1.1
Host: localhost:8080
name=hello&age=20
-> 클라이언트가 구 이벤트 페이지에서 name과 age를 입력하고 post요청을 날려준 상황
2. 응답 HTTP/1.1 308 Permanent Redirect
Location: /new-event
-> 으응 아냐아냐 이제 그런 링크 없어 /new-event로 옮겨줄게
3. 자동 리다이렉트, GET으로 변경
4. 요청 POST/new-event HTTP/1.1
Host:localhost:8080
name=hello&age=20
-> POST는 물론이고 메시지도 유지되었다!
5. 응답 HTTP/1.1 200 OK
-> 하지만 이 방법(308)은 실무에 잘 쓰이지 않는다. 왜냐하면 내부적인 데이터 값이 거의 바뀌기 때문에 GET으로 다시 돌리는게 맞다고 한다.
일시적인 리 다이렉션(302,307,303)
리소스의 URI 가 일시적으로 변경
따라서 검색 엔진 등에서 URL을 변경하면 안됨
- 302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문에 제거될 수 있음.
- 307 Temporary Redirect: 302와 기능은 같다 .리다이렉트시 요청 메서드와 본문 유지( 요청 메서드를 변경하면 안된다. Must Not)
- 303 See Other: 리다이렉트시 요청 메서드가 GET으로 변경
PRG: Post/Redirect/Get
일시적인 리다이렉션
ex )post로 주문후에 웹 브라우저를 새로고침하면? 새로 고침은 다시요청이며 중복 주문이 될 수 있다.
- POST로 주문후에 새로고침으로 인한 중복 주문 방지
- POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트
- 새로고침해도 결과 화면을 GET으로 조회
- 중복 주문 대신에 결과 화면만 GET으로 다시 요청
1.요청 POST /order HTTP/1.1
Host: localhost:8080
itemId=mouse&count=1
2. 주문 데이터 저장(DB)
3. 응답 HTTP/1.1 302 Found
Location: /order-result/18
4. 자동 리다이렉트
5. 요청 GET /order-result/18 HTTP/1.1
Host: localhost:8080
6. 주문 데이터 조회 18번 주문(DB)
7.응답 HTTP/1.1 200 OK
<html>주문 완료</html>
-304 not modified
캐시를 목적으로 사용한다.
클라이언트에게 리소스가 수정되지 않았음을 알려준다 -> 클라이언트는 로컬 PC에 저장된 캐시를 재 사용함.
304응답은 응답에 메시지 바디를 포함하면 안된다( 로컬 캐시를 재사용해야하므로)
조건부 GET,HEAD요청시 사용
4XX(Client Error):클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
400 Bad Request 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
ex) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을때
401 Unauthorized 클라이언트가 해당 리소스에 대한 인증이 필요함
인증 되지 않음
인증(Authentication) : 본인이 누구인지 확인, (로그인)
인가(UnAuthorized): 권한 부여(이 리소스에 대해 접근할 수 있는 권한이 있는 인증이 있어야 인가가 있음)
-> 이건 그냥 인증이 되지 않았다고 보는게 편함(로그인 안됐다고 보는것)
403 Forbidden 서버가 요청을 이해했지만 승인을 거부함
주로 인증 자격 증명은 있지만, 접근 권한이 불충분한경우
ex) 로그인 했지만 본인이 admin권한이 아니면 특정 권한 접근 불가
404 Not Found 요청 리소스를 찾을 수 없음
요청 리소스가 서버에 없음, 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를
숨기고 싶을때
5XX(Server Error): 서버 오류, 서버가 정상요청을 처리하지 못함
(서버에 문제가 있기 때문에 재시도하면 성공할 수 있다. 단, 복구가 되면)
-500 Internal Server Error
서버 문제로 오류가 발생한 것이며, 애매하면 500오류로 표시된다.
-503 Service Unavailable
서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없는 상태이다.
Retry-After헤더 필드로 얼마 뒤에 복구되는지 알 수 있다고 한다.
-> 500대 오류는 최대한 만드는 것을 지양한다!!!
출처- 김영한님의 HTTP 강의를 듣고 작성하였습니다.
www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard
모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의
실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., 웹 기술을 사용하는 개발자라면 누구나 OK!꼭 필요한 HTTP의 핵심을 알려드립니다. 📣 확인해주세요!본 강의는 자바 스
www.inflearn.com
'CS > Computer Network' 카테고리의 다른 글
HTTP 완벽 가이드 - 웹은 어떻게 동작하는가 서적 구입 (0) | 2021.03.20 |
---|---|
헤더 (0) | 2021.02.26 |
API URI 설계 (0) | 2021.02.24 |
HTTP 특징 (0) | 2021.02.24 |
URI와 웹 브라우저 요청 흐름 (0) | 2021.02.23 |