0. 개요
이번 게시물에서는 HTTP 상태코드 대해 작성할 것이다. 해당 게시물을 보기 전, 아래 링크의 글을 보고 오는 것을 추천한다.
(HTTP란?)
1. 상태코드
HTTP 응답 메시지 중 시작라인 (start-line)에 오는 코드로서, 클라이언트가 보낸 요청의 처리 상태를 알려주는 기능을 뜻한다. 그 종류로는
- 1xx (Informational): 요청이 수신되어 처리중
- 2xx (Successful): 요청 정상 처리
- 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
- 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없는 경우
- 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함
여기서 1xx는 거의 사용하지 않아 생략한다.
+ 만일에 클라이언트가 인식할 수 없는 상태코드를 서버가 반환한다면, 클라이언트는 상위 상태코드로 해석해서 처리한다.
ex) 299 ??? -> 아 일단 2xx 이구나! (Successful)
2. 2xx (Successful)
클라이언트의 요청을 성공적으로 처리하였다는 상태코드로, 자세한 코드들은 다음과 같다.
1) 200 OK
가장 많이 사용하게 되는 코드로, GET 같은 요청에 대해 성공적으로 결과를 처리한 후 응답을 할 경우, 해당 코드를 반환한다.
2) 201 Created
요청을 성공해서 새로운 리소스가 생성되는 경우, 해당 코드를 반환한다. 주로 POST 요청에 대해 사용되며, 생성된 리소스는 Location 헤더 필드를 통해 식별한다.
3) 202 Accepted
요청이 접수되었으나, 처리가 완료되지 않을 경우 반환한다. 배치 처리 같은 곳에서 사용하고, 예를 들어 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리할 경우 사용한다.
4) 204 No Content
서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없는 경우에 해당된다. 보통 PUT 요청에 대한 응답으로 많이 사용된다.
ex) 게시물 수정 중 save 버튼을 누르면, 작성중이던 게시물이 저장되었다는 응답을 보내야 하지만, 화면은 같은 화면을 유지해야 한다.
3. 3xx (Redirection)
해당 요청을 완료하기 위해 유저 에이전트(ex) 웹 브라우저)의 추가 조치가 필요한 경우에 사용한다. 웹 브라우저의 경우 3xx응답 결과에 Location 헤더가 있다면, Location 위치로 자동 이동된다.
ex) 기존에 event라는 주소를 사용하고 있었으나, 주소를 new-event로 변경하였다. 하지만 사용자가 기존 주소를 북마크 해두어서 예전 주소로 접속한다면? 이때를 위해 리다이렉션 기능이 있다.
- 서버에 /event 를 요청함
- 서버에서 Location: /new-event 이라고 알려주며 응답
- 클라이언트에서 자동으로 리다이렉트, Location에 있는 /new-event에 자동 접속
이런 리다이렉션에는 크게 3가지 종류가 있다.
1) 영구 리다이렉션
- 특정 리소스의 URI가 영구적으로 이동하는 경우이다.
- 즉, URI가 아예 바뀐 경우, 구 주소로 접속하는 사용자들을 새로운 주소로 가도록 해준다.
(1) 301 Moved Permanently
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다(MAY).
(2) 308 Permanent Redirect
- 301과 기능은 같지만, 리다이렉트시 요청 메서드와 본문을 유지한다.
-> 처음에 POST로 보내면 리다이렉트도 POST를 유지
실무에서는 영구 리다이렉션의 경우 거의 모든 경우에서 POST 사용을 유지할 필요는 없다. 페이지가 바뀌면서 필요한 파라이터나 정보들이 바뀌기 때문이며, 따라서 대부분 301 Moved Permanently를 선호한다.
2-1) 일시적 리다이렉션
- 리소스의 URI가 일시적으로 변경되는 경우이다.
- 따라서 검색 엔진 등에서 URL을 변경하면 안된다.
(1) 302 Found
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다(MAY).
(2) 307 Temporary Redirect
- 302와 기능은 같음
- 리다이렉트시 요청 메서드와 본물을 무조건 유지(MUST NOT).
(3) 303 See Other
- 302와 기능은 같음
- 리다이렉트시 요청 메서드가 "무조건" GET으로 변경
2-2) PRG: Post/Redirect/Get
- 일시적인 리다이렉션을 사용하는 예시이다.
- 만일에 POST로 어떤 상품을 주문한 후에 웹 브라우저를 새로고침한다면?
-> 새로고침은 다시 요청하라는 뜻
-> 중복 주문이 발생할 수 있다!
이미 POST 요청을 보내 주문 완료가 되었음에도 불구하고, 다시 새로고침을 하면 같은 상품을 한번 더 주문하게 된다. 이를 막기 위해서 계획을 세워보자.
- POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트 하자.
- 그 후 클라이언트가 새로고침을 해도 결과 화면을 다시 GET 요청하는 것이므로, 중복 주문이 아닌 결과 화면이 계속 뜨게 된다.
2-3) 그래서 302, 307, 303 중에 뭘 사용해야 함?
- 307, 303을 권장하지만, 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용하고 있다. 따라서 자동 리다이렉션시 GET으로 변해도 되면, 그냥 302를 사용해도 문제 없다.
3) 기타 리다이렉션
(1) 300 Multiple Choices
- 잘 사용하지 않는다.
(2) 304 Not Modified
- 캐시를 목적으로 사용한다.
- 클라이언트에게 리소스가 수정되지 않았으며, 따라서 저장된 캐시를 재사용하라는 메시지를 남긴다.
- 이는 응답에 메시지 바디를 포함하면 안된다.(로컬 캐시를 사용해야 하므로)
- 캐시에 대한 설명은 아래 게시글을 참고 바란다.
4. 4xx (Client Error)
오류의 원인이 클라이언트에 있는 경우에 사용된다. 클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없는 경우 반환하며, 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 재시도 하여도 실패한다.
1) 400 Bad Request
클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없는 경우이다.
- 요청 구문, 메시지 등등에서 오류가 발생한 경우
- 서버에서 스팩에 안맞는 요청이 들어온다면, 잘 검증해서 400 상태코드로 반환, 500 에러로 넘어가지 않도록 해야한다.
ex) 요청 파라미터 잘못됨, API 스펙이 맞지 않음
2) 401 Unauthorized
인증(Authentication)이 되지 않은 경우이다.
- 401 오류가 발생시, 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명해야 한다.
참고로 관련 용어를 정리해보면,
(1) 인증(Authentication)
- '유저'를 확인하는 작업, 접근한 대상이 어떤 종류의 유저인지 확인하는 과정
(2) 인가(Authorize)
- 해당 리소스에 접근한 대상이 권한이 있는지 확인하는 과정
(3) 권한(Authorization)
- 어떤 리소스에 대한 접근 제한을 의미, 모든 리소스는 각각 권한이 걸려있으며, 인가 과정에서 최소한의 권한을 확인하는 것
3) 403 Forbidden
서버가 요청을 이해는 했지만, 승인을 거부한 경우이다.
- 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우이다.(인가)
ex) 일반 사용자가 관리자 페이지에 접근하려고 할 경우
4) 404 Not Found
요청 리소스를 찾을 수 없는 경우이다. 2가지 가능성이 있다.
- 요청 리소스가 서버에 없음
- 클라이언트가 권한이 부족한 리소스에 접근 시, 해당 리소스를 숨기고 싶을 경우
5. 로직 에러가 나는 경우?
만일에 20살 이상인 경우에만 통과하도록 하는 로직을 만들었다고 생각해보자. 하지만 클라이언트에서 17살을 입력한 경우, 서버에서는 어떤 상태코드를 사용해야 할까?
이런 경우에는 클라이언트와 서버가 HTTP API 스펙이 정의를 어떻게 하였는지에 따라 달라질 것 같다. 만일에 정의를 했으면, 서버 측에서는 400으로 응답을 반환하고 클라이언트가 검증 로직을 만들어 20살 미만이면 서버로 요청이 넘어가지 않도록 해야한다.
하지만 만일에 HTTP API 스펙에 정리해 두지 않은 내용이라면, 200 OK 로 응답하되 결과에 내부 비즈니스 응답 코드를 정의해서 함께 전달한다. (승인, 거절 등등 정보 전달)
6. 5xx (Server Error)
서버 문제로 오류가 발생한 경우이다. 서버의 문제이므로, 재시도 시 성공할 수 있다.
1) 500 (Internal Server Error)
서버 문제로 오류가 발생한 경우로, 애매하면 500 오류를 사용한다.
- 중요!!! 정말 서버에 오류가 있을 때 사용해야 한다. 비즈니스 로직상의 문제가 있는 경우, 500 에러를 사용해서는 안된다.
2) 503 Service Unavailable
서비스 이용 불가한 경우이다.
- 서버가 일시적인 과부하 혹은 예정된 작업으로 요청을 잠시 처리할 수 없을때 발생한다.
- Retry-After 헤더 필드로 얼마 뒤에 복구되는지 보낼 수 있다.
-> 예측 불가능한 에러이기 때문에 503 상태코드를 보는 것은 흔치 않다.
- 참고한 글
위 내용은 김영한 님의 인프런 강의 "모든 개발자를 위한 HTTP 웹 기본 지식"의 내용과 강의자료를 토대로 작성된 게시글입니다.
강의 링크:
'cs > 컴퓨터 네트워크' 카테고리의 다른 글
| HTTP 쿠키 (0) | 2023.01.13 |
|---|---|
| HTTP 헤더 (0) | 2023.01.13 |
| HTTP API 설계하는 법 (0) | 2023.01.12 |
| HTTP 메서드(GET, POST, PUT, PATCH, DELETE) (0) | 2023.01.12 |
| HTTP란?, HTTP 메시지 (0) | 2023.01.12 |
댓글