[Network] HTTP Status code 📌

HTTP Status code (상태 코드) 란?

 

• HTTP 상태 코드는 웹 상에서 클라이언트가 보낸 HTTP 요청에 대한 서버의 응답 코드로, 상태 코드에 따라 요청의 성공/실패 여부를 판단할 수 있다
• HTTP 상태 코드는 크게 5가지로 분류된다
  • 1xx : Informational / 요청이 수신되어 프로세스를 계속한다
  • 2xx : Success / 요청을 성공적으로 받아 처리했다
  • 3xx : Redirection / 요청을 마치기 위해 추가 행동이 필요하다
  • 4xx : Client Error / 요청이 잘못되어 요청을 처리할 수 없다
  • 5xx : Server Error / 서버가 유효한 요청을 처리하는 데 실패했다

 

💡 Backend &Frontend 협업에서의 HTTP 상태 코드 설정의 중요성
- 백엔드에서 HTTP 상태 코드를 알맞게 설정해서 보내주지 않으면, 프론트엔드 단에서 불필요한 에러 처리를 추가해야 한다
- 따라서 좋은 분위기(?)의 협업을 하고 싶다면 귀찮더라도 백엔드에서 HTTP 상태 코드를 올바르게 설정해서 전달해주는 것이 좋다!

 

 

 

 

 

1️⃣ 1xx : Informational (조건부 응답)

• Request received, continuing process
• 요청을 받았으며 작업을 계속한다
• 사실상 거의 사용되지 않는다

 

 

 

 

2️⃣ 2xx : Success (성공)

• The action was successfully received, understood, and accepted
• 요청을 성공적으로 받았고, 인식했으며 수용함을 의미한다

• 200 OK
  • 요청이 성공적으로 수행되었다는 뜻으로, 성공의 의미는 HTTP 메서드에 따라 달라진다
  • GET - 리소스를 불러와서 메시지 바디에 전송했다
  • HEAD : 개체 헤더가 메시지 바디에 있다
  • PUT || POST : 수행 결과에 대한 리소스가 메시지 바디에 전송했다
  • DELETE : 삭제를 수행했고 응답 메시지가 이후의 상태를 설명한다
  • TRACE : 메시지 바디는 서버에서 수신한 요청 메시지를 포함하고 있다
• 201 Created
  • 요청을 통해 새로운 리소스가 생성되었을 때 사용하는 상태 코드이다
  • 일반적으로 POST 요청이나 일부 PUT 요청 이후에 따라온다
  • 대표적인 예시로는 회원가입, 게시글 작성 등의 경우가 있다
• 204 No Content
  • 요청이 정상적으로 수행되었고, 이 요청과 관련된 컨텐츠 또한 존재하지 않음을 의미한다
  • 주로 게시글 삭제 등과 같이 삭제 요청에 사용된다
  • 이 때 삭제 작업이 Soft Delete인지 Hard Delete인지는 상관없고, 그저 리소스가 삭제 되었음을 의미하는 코드이다

💡 Soft Delete vs Hard Delete
- Soft Delete : 논리 삭제 / 데이터 컬럼 값의 상태를 '삭제'로 변경하여 실제로 제거되진 않았지만 제거 상태를 띄고 있는 경우
- Hard Delete : 물리 삭제 / 실제 DB에서 데이터가 제거되어 더이상 존재하지 않는 경우

 

 

 

 

3️⃣ 3xx : Redirection (리다이렉션 완료)

• Further action must be taken in order to complete the request
• 요청 완료를 위해 추가 작업 조치가 필요함을 의미한다

• 301 Moved Permanetly
  • 이는 301 Redirect로 불릴만큼 리다이렉션 코드 중 가장 많이 사용되는 코드이다
  • 구글과 같은 검색 엔진의 봇들은 특정 페이지에 접근했는데 응답으로 301 상태 코드를 받을 경우, 자동으로 페이지 정보를 갱신하기도 하기 때문에 SEO(Search Engine Optimization) 관점에서도 이 상태 코드를 올바르게 사용하는 것이 중요하다
  • 이러한 리다이렉션 설정은 보통 서버 엔진의 설정 파일 내에서도 할 수 있고, 백엔드 어플리케이션 내에서 직접 할 수도 있다
  • 일반적인 경우 이 상태코드는 HTTP 프로토콜로 접속한 사용자를 HTTPS 프로토콜로 사용해야만 접근 가능한 포트로 보낼 때에도 많이 사용된다
  • ex) 80포트로 접속한 사용자를 발견한 Nginx는 HTTPS 프로토콜을 사용해야만 접근 가능한 443 포트로 리다이렉트시켜 해당 프로토콜 사용을 강제할 수 있다
• 304 Modified
  • 클라이언트가 요청한 리소스가 이전 요청과 비교했을 때 전혀 달라진 점이 없다는 것을 읨하낟
  • 서버가 응답으로 이 상태 코드를 보내면, 클라이언트는 굳이 서버에게 리소스를 재전송받아야 할 필요가 없기 때문에 자신이 캐싱해놓았던 리소스를 사용하게 되며, 이 과정에서 불필요한 통신 페이로드의 낭비를 줄일 수 있다
  • 이 과정에서 클라이언트는 서버로부터 요청한 리소스를 받은 것이 아닌, 자신이 캐싱해놓은 리소르를 사용하는 것이므로이 또한 캐싱된 리소스로 redirection되었다고 생각하는 것이다
  • 그래서 304 상태코드는 '암묵적인 리다이렉션'이라고 불리기도 한다
  • 만약 304 상태코드를 응답응로 받았는데 캐싱된 리소스가 없는 경우에는 빈 화면을 띄우거나 에러 화면이 노출되기 떄문에 이런 경우에는 브라우저에 캐싱된 리소스가 없다고 추측해볼 수 있겠다!

 

 

 

 

4️⃣ 4xx : Client Error (요청 오류)

• The request contains bad syntax or cannot be fulfilled
• 요청의 문법이 잘못되었거나 요청을 처리할 수 없음을 의미한다

• 400 Bad Request
  • 가장 많이 사용되는 400번대 코드
  • 그냥 클라이언트의 요청이 잘못되었음을 알려주기 때문에, 이유를 정확히 알려면 백엔드에서 로그를 확인해봐야 하는 경우가 발생할 수도 있다
• 401 Unathorized
  • 인증되지 않은 사용자가 인증이 필요한 리소스를 요청하는 경우, 인증이 필요함을 알려주는 상태코드이다
  • 보통 로그인이 필요한 API를 비로그인 사용자가 호출했을 때 많이 사용된다
  • 클라이언트에서 서버로부터 401 응답을 받으면, 로그인이 필요하다고 판단하고 로그인 페이지로 사용자를 리다리렉션 하기도 한다
• 403 Forbidden
  • 클라이언트가 접근이 금지된 리소를 요청했음을 의미한다
  • 이는 401과 헷갈릴 수 있는데 401은 인증이 되지 않았기 때문에 사용자의 신원을 파악하겠다는 느낌이고, 403은 사용자의 신원과 상관없이 해당 리소스를 요청하는 것 자체가 무조건 금지라는 뜻이다
  • 예를 들어 HTTPS 프로토콜로만 접근해야 하는 리소스에 HTTP 프로토콜로 접근하는 경우 서버에서 403 응답을 보내주기도 한다
• 408 Request Timeout
  • 클라이언트와 서버의 연결은 성사되었지만 요청의 본문이 계속 서버에 도착하지 않는 상황을 의미한다
  • HTTP 프로토콜을 사용하여 통신을 할 때는 반드시 클라이언트와 서버 간의 연결을 생성하고, 그 이후에 요청 본문에 해당하는 데이터를 전송하게 된다
  • 이 때 408 상태 코드는 이 과정에서 연결은 제대로 생성되었지만, 서버가 아무리 기다려도 클라이언트가 보낸 요청 본문을 받지 못하는 경우에 발생하게 된다
• 429 Too Many Requests
  • 클라이언트가 서버에 너무 요청을 많이 보내는 경우에 발생한다
  • 이는 너무 짧은 시간동안 빠르게 다수의 요청을 보낸 경우일 수도 있고, 유료 API를 사용하는 경우에는 현재 요금에서 사용 가능한 API 요청 횟수를 초과한 경우일 수도 있다
  • 서버에서는 429 상태 코드와 함께 응답 헤더의 Retry-After 라는 필드를 사용하여 이후 재 요청을 시도하라는 의미를 전달할 수도 있다

 

 

 

 

5️⃣ 5xx : Server Error (서버 오류)

• The server failed to fulfill an apparently valid request
• 서버가 명백히 유효한 요청에 대해 충족을 실패했음을 의미한다

• 500 Internal Server Error
  • 백엔드 어플리케이션 내에서 뭔가 알 수 없는 에러가 발생했다는 의미이다
  • 대부분 제대로 핸들링되지 않은 에러가 발생한 경우가 많아서, 에러의 원인을 클라이언트에게 알려주지 않는다 (사실상 알려주지 못하는 것이다...^^)
• 501 Not Implement
  • 서버에 요청을 수행할 수 있는 기능이 없다
  • 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다
• 502 Bad Gateway
  • 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다
  • 해당 코드를 받는 가장 흔한 상황은 백엔드 어플케이션이 죽은 상황이다
• 503 Service Unavailable
  • 서버가 오버로드 되었거나 유지관리를 위해 다운되어서 현재 서버를 사용할 수 없다
  • 이는 대개 일시적인 상태이다
• 504 Gateway Timeout
  • 이는 408 Request Timeout과 마찬가지로 요청에 대한 Timeout을 의미한다
  • 그러나 504 상태코드는 클라이언트의 요청에 의해 발생하는 것이 아니라, 백엔드 아키텍처 내부에서 서버끼리 주고받는 요청에서 발생하는 것이다

 

💡 502 Bad Gateway
- 서버가 죽은 상황에 주로 발생하지만 서버가 죽었다는 메시지가 아닌 Bad Gateway인 이유는 무엇일까?
- 이는 아무리 간단한 구조라고 해도 절대 어플리케이션 1개로만 구성되지 않기 때문이다
- 여기서 게이트웨이란 어플리케이션 간의 추상적인 연결점을 의미하는데, 이 메시지가 의미하듯 백엔드의 아키텍처는 최소 2개 이상의 어플리케이션으로 구성된 경우가 대부분이다
- 일반적인 경우 클라이언트가 보낸 요청은 곧바로 백엔드 어플리케이션에 전달되지 않고, 백엔드 앞단의 아파치나 Nginx 같은 서버 엔진이나 로드밸런서가 대신 요청을 받아서 백엔드 어플리케이션으로 전달된다
- 이런 아키텍처를 사용하게 되면 백엔드 앞 단에 프록시 서버를 두어 문지기 역할을 시키기 때문에 보안과 처리 효율이 향상된다
- 따라서 백엔드 어플리케이션이 죽어버리는 경우, 앞 단의 게이트웨이인 프록시 서버는 백엔드 서버로부터 어떤 응답도 받지 못하게 되기 때문에 클라이언트에게 502 Bad Gateway라는 메시지를 보내는 것이다

 

 

 

---

HTTP 상태코드 FAQ

 

Q. 로그인 실패 시 상태 코드는?

• 400 Bad Request 를 보낸다
• 인증 정보와 일치하지 않는 정보를 전달했으므로 클라이언트의 잘못된 요청으로 판단한다

 

 

Q. 토큰을 사용할 경우 토큰 만료 상태 코드는?

• 401 Unathorized 를 보낸다
• 토큰이 만료되었다는 것은 더 이상 해당 요청은 인증되지 않은 요청으로 간주한다

 

 

Q. 301 Moved Permanently vs 302 Found

• 301 Moved Permanetly
  • 영구적으로 요청에 대한 결과 처리 경로가 변경됨
  • SEO에서 새로운 페이지를 인지하여 과거 URL의 기존의 페이지 랭킹과 평가 점수를 새로운 URL로 이동시킨다
• 302 Found
  • 임시적으로 리다이렉트 되었다
  • SEO에서 기존 URL을 유지한다

 

 

Q. 401 Unathorized vs 403 Forbidden

• 401 Unathorized : 인증되지 않은 요청을 의미한다
• 403 Forbidden : 인증은 되었지만 요청에 대한 권한이 부족하다는 것을 의미한다
• 즉, 401은 권한보다는 인증의 개념으로 이해하는 것이 쉽다

 

 

Q. 4xx vs 5xx

• 두 종류의 상태 코드는 서버 입장에서 요청이 잘못된 경우와 요청의 처리 과정 중 잘못된 경우로 나뉜다
• 4xx 오류는 클라이언트의 요청이 잘못된 경우이기 때문에 서버 측에서 예상이 가능한 오류이다
• 5xx 오류는 프로그래머의 실수나 외부 API에 대한 이해 부족으로 발생하기 때문에 예상하지 못한 오류이다
• 따라서 일반적으로 5xx 오류는 클라이언트에게 보여주면 안된다
• 5xx 오류는 명백히 서버의 잘못이기 때문에 되도록 모든 예외는 서버 측에서 처리하거나 클라이언트 입장에서 의미있는 4xx 오류로 변환하여 전달하는 것이 좋다

 

 

 

---

참고)

https://velog.io/@sangyeon217/http-status-code

HTTP 상태 코드

https://evan-moon.github.io/2020/03/15/about-http-status-code/

서버의 상태를 알려주는 HTTP 상태 코드

https://surprisecomputer.tistory.com/47

[Network] HTTP 상태(응답) 코드 정리하기

https://incheol-jung.gitbook.io/docs/q-and-a/computer-science/http-status-todo

HTTP STATUS - Incheol's TECH BLOG

https://evan-moon.github.io/2020/03/15/about-http-status-code/

서버의 상태를 알려주는 HTTP 상태 코드

https://tecoble.techcourse.co.kr/post/2020-08-31-http-status-code/

상태 코드, 뭘 줘야할까?