HTTP | 섹션 6. HTTP 상태코드

728x90

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC#

모든 개발자를 위한 HTTP 웹 기본 지식 강의 - 인프런

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., [사진] 📣 확인해주세요!본 강의는 자바 스프링 완전 정복 시리즈의 세 번째 강의입니다. 우아한형제들 최연소 기술

www.inflearn.com

🟦 섹션 6. HTTP 상태코드

⬛ 1. HTTP 상태코드 소개

◼️ HTTP 상태코드 란?

클라이언트가 서버로 요청을 보내면 요청의 처리 상태를 응답해서 알려주는 기능이다.

◼️ HTTP 상태코드 예시

1xx (Informational) : 요청이 수신되어 처리중 (거의 사용 X)

2xx (Successful) : 요청 정상 처리

3xx (Redirection) : 요청 완료하려면 추가행동 필요

4xx (Client Error) : 클라이언트 오류 때문에 서버가 요청 수행X

5xx (Server Error) : 서버 오류. 서버가 정상 요청 처리 X

→ 만약 모르는 상태 코드가 나타나면, 상위 상태코드 번호로 해석하면 된다.

ex. 299 → 2xx (Successful)

ex. 451 → 4xx (Client Error)

⬛ 1xx (Informational)

요청이 수신되어 처리 중
거의 사용X 생략

⬛ 2xx (Successful) : 성공

◼️ 200 OK | 요청 성공

클라이언트의 요청을 서버가 성공적으로 처리했다는 상태코드

◼️ 201 Created | 신규 리소스 생성했다.

클라이언트가 요청 성공(POST)해서 서버에서 새로운 리소스 생성했다는 상태코드이다.
HTTP 헤더 Location에 생성된 신규 리소스 URI를 넣어준다.
주로 POST로 201 Created 한다.

◼️ 202 Accepted | 클라이언트 요청은 접수 O, 처리는 완료 X

요청이 접수되었지만 처리는 완료되지 않은 상태코드
잘 사용하지 X
ex. 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처

◼️ 204 No Content

서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
ex. 웹 문서 편집기에 저장 버튼 누를 때, 웹 문서가 POST를 해서 서버로 전달한다. 이때는 서버에서 그냥 저장했다.
이때는 따로 응답 페이로드 본으로 보낼 데이터가 없다.
즉, 저장 버튼 누르고 계속 편집을 할 거라 결과에는 아무 내용이 없는 거다.

⬛ 3xx (Redirection) | 리다이렉션

요청을 완료하기 위해 유저 에이전트의 추가 조치 필요한 상태 코드
클라이언트가 서버에 요청을 했는데 서버가 요청을 완료하려면 추가 작업이 필요해서 클라이언트에게 다시 보낸다.

◼️ 리다이렉션 이해

웹 브라우저는 3xx 응답 결과에 Location 헤더가 있으면, Location 위치로 자동으로 이동하는데, 이를 두고 (리다이렉트) 라고 명명한다.
아래의 그림을 예시로 보자.
클라이언트가 /event 페이지로 GET 요청을 보냈는데, 서버는 더 이상 사용하지 않는 해당 페이지의 새 위치를 Location헤더에 /new-event 담아 상태코드 301로 응답한다.
클라이언트는 바뀐 새 경로로 자동 리다이렉트 되어 다시 GET/new-event 페이지로 서버에 요청을 하게 되고, 서버는 처리 완료 후 그 응답 HTML을 클라이언트에 보내게 된다.

◼️ 리다이렉션 종류 | 3가지

1) 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동

ex) /members → /users : 아예 영구적 변경
ex) /event ⇒ /new-event

2) 일시 리다이렉션 - 일시적인 변경

주문 완료 후 → 주문 내역 화면으로 이동
PRG : Post/Redirect/Get

3) 특수 리다이렉션

결과 대신 캐시를 사용한다.

🟦 1) 영구 리다이렉션

영구 리다이렉션 상태코드는 301, 308 이다.
리소스 URI가 영구적으로 이동한 것이다.
그런데, 원래의 URL은 사용 X, 검색 엔진 등에서도 변경을 인지한다.
검색엔진은 새로운 URI로 써야 한다.

◼️ 301 Moved Permanently

추후 리다이렉트 요청 메서드는 GET으로 변하고, 본문 메시지가 제거될 수 있다

아래 그림예시로 보자. 클라이언트가 /event 로 HTTP 바디 메시지에 사용자를 event에 등록하겠다고 POST로 요청했다. 서버에서는 더 이상 사용하지 않으니 /new-event로 쓰겠다고 클라이언트에게 301 상태코드를 보낸다. 그러면 클랄이언트는 새 경로로 자동 리다이렉트 되는데, 리다이렉트 이후의 요청 메서드가 GET으로 변하고 본문이 제거될 수 있다는 거다.

→ 이렇게 되면 새로운 페이지에서 다시 입력해야 하는 폼 화면이 나와 사용자는 처음부터 다시 입력해야 한다.이러한 불편한 점 때문에 308 상태코드가 등장한다.

◼️ 308 Permanent Redirect

301과 기능은 같음
리다이렉트 시 요청 메서드와 본문 메시지도 유지 (처음 POST 보내면 리다이렉트도 POST)

클라이언트가 /event 내부에 HTTP 바디 메시지에 사용자를 event에 등록하겠다고 POST로 요청하면 서버는 /new-event 를 쓰겠다고 클라이언트에게 308 상태코드를 보내는데, 이때 새 경로로 리다이렉트된 이후에ㄷ, 요청 시에 POST를 그대로 유지하면서 && HTTP 바디 메시지도 그대로 유지된다.

→ 그런데 실무에서는 잘 사용 X

→ 이유 : /event → /new-event로 바뀌면 내부적으로 전달해야 하는 데이터 자체가 바뀌어버린다. 그래서 POST로 와도 웬만하면 GET으로 돌리는 경우가 더 많다.

🟦 2) 일시적인 리다이렉션

일시적 리다이렉션 상태코드는 302, 307, 303 이다.

리소스의 URI가 일시적으로 변경한다.
따라서 검색 엔진 등에서 URI를 변경하면 안된다.
실무적으로 많이 쓰인다.

◼️ 302 Found

리다이렉트 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음

◼️ 307 Temporary Redirect

302와 기능은 같음
리다이렉트 요청 메서드와 본문 유지 (요청 메서드 변경 X 못함)

◼️ 303 See Other

302와 기능은 같음
리다이렉트 요청 메서드가 GET으로 변경

◼️ PRG : POST/Redirect/ Get | 일시적 리다이렉션의 예시

Post로 주문 후에 새로고침으로 인한 중복 주문 방지하고 주문 결과 화면을 GET메서드로 리다이렉트 한다.
즉, 리다이렉트 후 재 요청시, 새로고침 결과화면을 GET으로 조회한다.
즉, 리다이렉트 후 재 요청 시, 중복 주문 대신 결과 화면만 GET으로 요청한다는 거다.

🟩 PRG 사용 전 모습

클라이언트가 /order에 Post로 상품 주문 요청을 하면, 서버에서는 상품 주문이 들어왔다고 주문 데이터베이스에 저장을 하고, 200 상태코드를 보내고 주문 완료 페이지를 보낸다.
만약 실수로 새로고침을 다시 하면, 또 다시 POST로 주문 DB에서 1개의 중복 주문 건이 다시 저장되고, 클라이언트 화면에는 또 다시 주문 완료 페이지가 뜨게 된다.
여기서 서버에서는 클라이언트가 실수할 사항을 막아야 한다.

🟩 PRG 사용 후

클라이언트가 /order에 Post 로 상품주문 요청을 하게 되면,서버에서 주문이 들어왔다고 주문 DB에 저장을 하고 302 상태 코드와 /order-result/19 Location 정보를 준다.
클라이언트가 300 상태코드를 보고 GET메서드로 리다이렉트
주문 데이터 저장한 거를 쌓는 게 아니라, /order-result/19 주문 정보를 조회해서 HTML 화면을 만들고 200 상태코드를 보낸다.
여기서 클라이언트가 실수로 새로고침을 해도 중복 주문이 아니라 /order-result/19에 대한 GET 주문 데이터를 조회하게 된다.

🟦 3) 기타 리다이렉션 : 300, 304

◼️ 300 Multiple Choices : 안쓴다.

◼️ 304 Not Modified

캐시 목적으로 사용
클라이언트에게 해당 리소스가 수정사항 없음을 알려준다.
따라서 클라이언트는 로컬 PC에서 저장된 캐시를 재사용한다**.(즉, 캐시로 리다이렉트한다.)**
304 응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시 사용해야 하기 떄문)
조건부 GET, HEAD 요청 시 사용

⬛ 4xx (Client Error) | 클라이언트 오류

클라이언트의 요청에 잘못된 문법 등으로 서버가 요청 수행할 수 없는 상태코드
오류의 원인 : 클라이언트
이미 클라이언트의 잘못된 요청/데이터 보내고 있는 것이므로, 똑같은 재시도는 또 다시 실패함

◼️ 400 Bad Request

클라이언트가 잘못된 요청을 해서 서버가 해당 요청 수행 불가한 상태이다.
주로, 요청 구문, 메시지 등으로 오류난다.
클라이언트는 요청 내용을 다시 검토 후 보내야 한다.
요청 파라미터가 잘못되었거나 API 스펙이 맞지 않을 때 주로 나타난다.

◼️ 401 Unauthorized

클라이언트가 해당 리소스에 대한 인증(Authentication)이 되지 않았다는 거다.
401 오류 발생 시 응답에 WWW-Authenticate 헤더와 함께 인증 방식을 설명해야 한다.

인증 (Authentication) : 본인이 누구인지 확인 (로그인)

인가 (Authorization) : 권한 부여 (ADMIN 권한처럼 특정 리소스에 접근 권한 인증 있어야 인가 있음)

오류 메시지가 Unauthorized 이지만 인증 자체가 안된다는 뜻이다. (이름이 아쉬움)

◼️ 403 Forbidden

서버가 요청을 이해했지만 승인을 거부함
주로 인증 자격 증명은 있지만, 접근 궈한 불충분한 경우
ex) 어드민 등급 아닌 사용자 로그인 후, 어드민 등급의 리소스에 접근하는 경우

◼️ 404 Not Found

요청 리소스가 서버에 없다.
또는 클라이언트가 권한 부족한 리소스에 접근 시 해당 리소스를 숨기고 싶을 때

⬛ 5xx (Server Error) | 서버 오류

서버 문제로 오류 발생
서버에 문제 있기 때문에, 재시도 시 성공할 수도 있음 (중간에 복구 되거나 하면)

◼️ 500 Internal Server Error

서버 내부 문제로 오류 발생.
애매하면 500 오류

◼️ 503 Service Unavailable

서비스 이용 불가
서버가 일시적 과부하 또는 예정된 작업으로 잠시 요청 처리할 수 없음
Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음