이번 글에서는 HTTP 상태코드에 대해 알아보고자 한다.
상태코드란 무엇일까?
상태코드란, 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능이다.
- 1xx(Informational) : 요청이 수신되어 처리중
- 2xx(Successful) : 요청 정상 처리
- 3xx(Redirection) : 요청을 완료하려면 추가 행동이 필요
- 4xx(Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수핼할 수 없음
- 5xx(Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함
만약, 모르는 상태코드를 클라이언트가 서버로부터 받게 된다면, 클라이언트는 상위 상태코드로 해석해서 처리하고
나중에 새로운 상태 코드가 서버에 추가되어도 클라이언트를 변경하지 않아도 된다는 장점이 있다.
예를 들어, 423이라는 상태코드를 클라이언트가 모를 경우 -> 클라이언트는 4xx(Client Error)로 처리한다.
또한, 523이라는 상태코드를 클라이언트가 모를 경우 -> 클라이언트는 5xx(Server Error)로 처리한다.
다음으로, 상태코드에 대해 자세히 알아본다.
- 2xx
2xx(Successful)에는 대표적으로 다음과 같은 상태코드가 있다.
- 200 OK (요청 성공)
- 201 Created (요청 성공해서 새로운 리소스가 생성됨)
- 202 Accepted (요청이 접수되었으나 처리가 완료되지 않았음)
- 204 No Content (서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음)
- 200 OK
위와 같은 Controller 설계코드에서 PostMan을 이용해 해당 URI로 요청을 진행해본다.
요청이 성공했을 경우, 오른쪽 우측 상단에 200OK를 확인할 수 있다.
다음으로 201 Created에 대해 알아본다.
- 201 Created
위와 같은 Controller 설계코드에서 PostMan을 이용해 해당 URI로 요청을 진행해본다. 이때, 요청이 성공해서 새로운 리소스가 생성되게 된다면, HTTP 메세지 응답 헤더 Location 필드에 해당 리소스의 위치를 값으로 넣는것이 중요하다.
HTTP 메세지 응답 헤더의 Location 필드에 값이 제대로 들어간 모습을 확인할 수 있고, 상태코드는 201임을 파악할 수 있다.
- 202 Accepted
202 Accepted는 요청이 접수되었으나 처리가 완료되지 않을 경우인데, 예를 들어 요청 접수 후에 1시간 후에 배치 프로세스가 요청을 처리하는 경우이다.
- 204 No Content
서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없는 경우이다.
예를 들어, 웹 문서 편집기에서 save 버튼을 누르면 save 버튼의 경과로 아무 내용이 없어도 되고, 버튼을 눌러도
같은 화면을 유지해야 하며 결과 내용이 없더라도 204 메세지만으로 성공을 인식할 수 있다.
- 3xx
3xx(Redirection)에는 대표적으로 다음과 같은 상태코드가 있다.
- 300 Multiple Choices
- 301 Moved Permanently
- 302 Found
- 303 See Other
- 304 Not Modified
- 307 Temporary Redirect
- 308 Permanent Redirect
리다이렉션을 이해하기 위해서는 다음과 같은 내용을 알아야 한다.
- 웹 브라우저가 3xx응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동한다.
상태코드를 알아보기 전에, 리다이렉션의 종류에 대해서 알아본다.
리다이렉션의 종류에는 영구 리다이렉션, 일시 리다이렉션, 특수 리다이렉션이 있다.
- 영구 리다이렉션이란 특정 리소스의 URI가 영구적으로 이동하는 것이다. 원래의 URL을 사용하는 것이 아니며, 301, 308 상태코드가 있다.
- 일시 리다이렉션이란 일시적인 변경이다. 예를 들어 주문 완료 후 주문 내역 화면으로 이동하는 경우가 있고대표적으로 PRG: Post/Redirect/Get라는 개념이 있다. 302, 307, 303 상태코드가 있다. PRG라는 개념이 나오게 된 이유는 다음과 같다. 만약, POST로 주문 후에 웹 브라우저를 새로고침하면? 새로고침은 다시 요청이기 때문에 중복 주문이 될 수 있다. 따라서, PRG는 POST로 주문후에 새로 고침으로 인한 중복 주문을 방지하는 것이다. POST로 주문 후에 주문 결과 하면을 GET메서드로 리다이렉트하는 것이며 새로고침을 실수로 누른다고 하더라도 결과 화면을 GET으로 조회한다. 중복 주문 대신에 결과 화면만 GET으로 다시 요청한다. -> 3개의 상태코드 중 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용하므로 302를 사용해도 큰 문제 없다.
- 특수 리다이렉션이란 결과 대신 캐시를 사용한다.
- 4xx
4xx(Client Error)에는 대표적으로 다음과 같은 상태코드가 있다.
- 400 Bad Request
- 401 Unauthorized
- 403 Forbidden
- 404 Not Found
- 400 Bad Request
클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없는 경우이다. 요청 구문, 메세지 등등의 오류가 될 수 있다.
클라이언트는 요청 내용을 다시 검토하고 보내야 한다. 예를 들어 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 경우이다.
스프링을 통해 예를 들어 알아본다.
위와 같이 코드가 설계되었다고 할때, PostMan을 통해 400 상태코드가 나올 수 있는 경우는 어떤 것이 있을까?
HTTP 요청 메세지의 Body에 name필드의 값이 2자리 이상이 아니라면, 400 Bad Request 상태코드가 나오는 모습을 확인할 수 있다.
- 401 Unauthorized
클라이언트가 해당 리소스에 대한 인증이 필요할 경우에 사용된다.
인증이란? 본인이 누구인지 확인하는 것이다.
인가란? ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한을 의미한다. 인증이 있어야 인가가 있다.
예를 들어, 스프링 시큐리티와 JWT를 이용하는 시스템의 경우, HTTP 메세지 요청 헤더에 인증토큰이 잘못된 경우
해당 오류가 발생할 수 있다.
- 403 Forbidden
서버가 요청을 이해했지만 승인을 거부한 경우이다.
주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우에 발생한다.
예를 들어 어드민 등급이 아닌 사용자가 로그인은 했지만, 어드민 등급의 리소스에 접근하는 경우이다.
- 404 Not Found
요청 리소스를 찾을 수 없는 경우이다. 요청 리소스가 서버에 없을 때나 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때 사용한다.
스프링 코드를 통해 예를 들어 알아본다.
다음과 같이, 서버에 User의 id가 5번인 리소스가 없을 경우 404 Not Found 상태코드가 나오는 것을 확인할 수 있다.
- 5xx
5xx(Server Error)에는 대표적으로 다음과 같은 상태코드가 있다. 서버에 문제가 있기 때문에 재시도 하면 복구가 될 경우 성공할 수도 있다.
- 500 Internal Server Error
- 503 Service Unavailable
- 500 Internal Server Error
서버 문제로 오류가 발생했을 경우이다. 애매하면 500 오류를 사용하도록 한다.
- 503 Service Unavailable
서버가 일시적인 과부하나 예정된 작업으로 잠시 요청을 처리할 수 없는 경우이다.
Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수 있다.
'Dev > Network' 카테고리의 다른 글
[Network] OSI 7 계층의 Session Layer(세션 계층), Presentation Layer(표현 계층)에 대한 개념 정리 (0) | 2022.01.10 |
---|---|
[Network] OSI 7 계층의 Top Layer(전송 계층)에 대한 개념 정리 (0) | 2022.01.10 |
[Network] OSI 7 계층의 Network Layer(네트워크 계층)에 대한 개념 정리 (0) | 2022.01.10 |
[Network] SOAP, REST의 개념과 차이점 정리 (0) | 2022.01.10 |
[Network] CORS(Cross Origin Resource Sharing)란? (0) | 2022.01.10 |