[WEB/HTTP] 06. HTTP 상태코드

 

 

이 글은 인프런 강의 "모든 개발자를 위한 HTTP 웹 기본 지식" 을 학습하며 정리한 내용입니다.

저처럼 HTTP를 알고 싶거나, 겉핥기로 알고 있는 분들에게 위 강의를 추천합니다.

 

정리한 내용 중 틀린 내용이 있으면 지적해주시면 수정하겠습니다.

---

HTTP 상태코드

클라이언트가 보낸 요청의 처리상태를 응답해서 알려주는 기능

 

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

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

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

- 4xx (Client Error) : 클라이언트 측 오류

- 5xx (Server Error) : 서버 측 오류

 

모든 HTTP 상태코드를 모르더라도 몇 번 백대인 지 확인하고, 해당 상태 코드를 예측할 수 있습니다.

---

2xx (Successful)

클라이언트의 요청을 성공적으로 처리

 

- 200 OK : 요청 성공

- 201 Created : 요청 성공해서 새로운 리소스가 생성

- 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않음

- 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 바디에 보낼 데이터가 없음

---

3xx (Redirection)

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동한다. (리다이렉트)

 

영구 리다이렉션 : 특정 리소스 URI가 영구적으로 이동

도메인이 아예 변경되었거나, 새로운 URI 구조로 변경했을 때

기존에 사용자들이 북마크 기능 등, 예전 리소스로 접근했을 때 영구 리다이렉션을 통해 변경된 리소스로 유도

 

- 301 Moved Permantely : 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음

POST 요청 ->  URI 리다이렉트 -> GET 요청

 

- 308 Permanent Redirect : 리다이렉트시 요청 메서드와 본문을 유지함

POST 요청 -> URI 리다이렉트 -> POST 요청, BODY 유지

 

301은 회원가입 요청 시 리다이렉트되면 GET으로 변경되므로 다시 데이터 작성 후 요청

308은 회원가입 요청 시 리다이렉트되면 POST, BODY를 유지하므로 바로 POST 요청 가능

 

일시적인 리다이렉션 : 리소스의 URI가 일시적으로 변경

회원가입 시 일시적인 리다이렉션을 하지 않으면 회원가입 후 새로고침으로 중복 가입이 될 수 있다.

이럴 때 POST 회원 가입 후 회원 가입 결과 화면 등으로 GET 메서드로 리다이렉트 해줘야 한다.

그러면 새로 고침을 해도 결과 화면을 GET으로 조회한다.

 

- 302 Found : 요청 메서드가 GET으로 변할 수 있음

- 307 Temporary Redirect : 요청 메서드가 변화하지 않음

- 303 See Other : 메서드가 GET으로 무조건 변경 

 

의미가 명확한 307, 303을 권장하지만, 기존 애플리케이션들이 이미 302를 기본값으로 사용

GET으로 변해도 되면 302를 사용해도 큰 문제없음

 

기타 리다이렉션

304 Not Modified : 캐시를 목적으로 사용

 

클라이언트가 GET으로 요청할 때, 데이터를 응답하지 않고 캐시로 리다이렉트 한다.

따라서 클라이언트는 로컬에 저장된 캐시를 사용한다.

응답 메시지 바디는 포함하면 안 된다.

---

4xx (Client Error)

클라이언트 측 오류

클라이언트에서 이미 잘못된 요청을 보낸 것이므로, 재시도를 해도 똑같이 실패함

 

- 400 Bad Request : 잘못된 요청(요청 파라미터가 잘못되었거나, API 스펙 불일치)

- 401 Unauthorized : 인증되지 않음, (로그인이 안 돼있음)

- 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함(로그인은 되어있지만 권한이 없음)

- 404 Not Found : 요청 리소스를 찾을 수 없음 

---

5xx (Server Error)

서버 측 오류

서버에 문제가 있기 때문에 재시도하면 성공할 수 있음(DB, 서버 복구 등) 

 

- 500 Internal Server Error : 서버 내부 문제(애매하면 500)- 503 Service Unavailable : 서비스 이용 불가(서버 다운)

 

5xx 대 에러는 정말 서버의 장애나 에러가 났을 때만 발생시켜야 함.비즈니스 로직이나 프로세스 상 논리적인 문제가 발생 시 내는 경우가 있는데, 사용하면 안 된다

---

참고사항 : 그럼 비즈니스 로직에 의한 예외들은 어떤 응답을 주어야 할까?

1. 요청이 서로 약속한 HTTP API 스펙에 만족하고 정상 처리된다면?

- 만족 : 2xx

- 불만족 : 4xx

 

2. 요청서로 약속한 HTTP API 스펙에 만족하지만, 내부 비즈니스 로직에 의해 결과가 분기(승인, 거절) 된다면?

- 2xx + 비즈니스 코드 반환 (봉투 패턴이라고 함)

 

HTTP 스펙상 문제가 없으므로 2xx대로 응답하면서, 비즈니스 로직에 관한 데이터를 포함해서 응답하는 방식

 

3. 내부에서 시스템 예외 등 서버 측 오류 발생

- 500

 

복잡한 비즈니스 로직이 필요한 API 개발 시 봉투 패턴을 고려

단순한 API는 봉투 패턴을 사용하지 않음, 봉투 패턴 남발 시 응답 구조가 복잡해질 우려 !

 

위 내용은 정답이 아닌 참고사항입니다.

상황에 맞게 적절하게 사용법을 고민합시다.