[네트워크] HTTP Status Code

 

 

HTTP Status Code

 

클라이언트에서 오는 HTTP 요청에 대한 응답입니다.

각각의 응답코드 번호는 다음을 나타냅니다.

1. Informational responses (100 – 199)
2. Successful responses (200 – 299)
3. Redirection messages (300 – 399)
4. Client error responses (400 – 499)
5. Server error responses (500 – 599)

다양한 웹을 사용하는 클라이언트 및 개발자들은 위와같은 수많은 Response code를 맞닥뜨리게 됩니다.

수많은 Code들 중 잘 알려진 코드들에 대해 어느정도 숙지를 해놓는다면 시기적절하게 대처할 수 있을거라 생각도 됩니다.

 

다음으로는 각각의 Response 중 Well Known Code들에 대해서 간단하게 살펴보겠습니다.

 

 

Informational responses (100 – 199)

사실 100번대 Status Code는 다룰 일도 마주칠 일도 별로 없다고 생각됩니다.

여기서는 한가지의 Code에 대해서만 알아보고 넘어가도록 하겠습니다.

100 Continue

이 임시 응답은 클라이언트가 요청을 계속해야 하거나 요청이 이미 완료된 경우 응답을 무시해야 함을 나타냅니다.

 

---

Successful responses (200 – 299)

클라이언트의 요청이 서버에서 성공적으로 처리되었다는 의미입니다.

200 OK

요청이 성공했을 때의 응답입니다. “성공”의 결과 의미는 HTTP Method에 따라 다릅니다.

• GET
• : 리소스를 가져와 메시지 본문에 전송했습니다.
• HEAD
• : 표현 헤더는 메시지 본문 없이 응답에 포함됩니다.
• PUT 또는 POST
• : 작업 결과를 설명하는 리소스가 메시지 본문에 전송됩니다.
• TRACE
• : 메시지 본문에는 서버에서 수신한 요청 메시지가 포함됩니다.

201 Create

대부분 POST에 대한 응답코드입니다.

요청이 성공했으며, 결과적으로 새 리소스가 생성되었음을 나타냅니다.

202 Accept

요청이 수신되었지만 아직 실행되지 않았을 때의 응답코드입니다.

HTTP 통신에서 서버가 추후에 따로 비동기 응답 통신을 할 수 있는 방법은 없기 때문에 비커밋 응답을 나타냅니다.

다른 프로세스나 다른 서버가 해당 요청을 처리할 때 혹은 일괄 처리를 위해 사용됩니다.

 

---

Redirection messages (300 – 399)

완전한 처리를 위해서 추가 동작이 필요한 경우입니다.

주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니 그 주소로 다시 시도하라는 의미입니다.

300 Multiple Choices

요청에 가능한 응답이 2개 이상 존재할 때 사용하는 응답코드입니다.

사용자가 둘 중 하나를 선택할 수 있도록 HTML 링크를 제공하는 것이 추천됩니다.

 

301 Moved Permanently

요청한 리소스의 URL이 영구적으로 변경되었습니다.

새 URL이 응답에 제공됩니다.

 

302 Found

이 응답 코드는 요청한 리소스의 URI가 일시적으로 변경되었음을 의미합니다.

앞으로 URI가 추가로 변경될 수 있습니다. 따라서 클라이언트는 향후 요청에서도 동일한 URI를 사용해야 합니다.

---

Client error responses (400 – 499)

없는 페이지를 요청하는 등 클라이언트의 요청 메시지 내용이 잘못된 경우를 의미합니다.

400 Bad Request

클라이언트 오류로 인식되는 상황으로 요청을 처리할 수 없거나 처리하지 않을 때 사용하는 응답코드입니다.

자주 볼 수 있는 응답코드로써 다음과 같은 예시상황들이 있습니다.

1. 구문 오류 : 요청에 잘못된 구문이나 형식이 포함되어 있어 서버에서 이해할 수 없습니다.
2. 정보 누락 : 서버에 필요한 필수 정보를 생략하면 400 Error가 발생할 수 있습니다.
3. 인증 문제 : 사용자의 자격 증명이 유효하지 않거나 누락된 경우 서버에서 요청을 거부할 수 있습니다.

401 Unauthorized

사용자 자격 증명이 유효하지 않을 때 사용하는 응답코드입니다.

이를 해결하기 위해서는 클라이언트 측에서 자격 인증이 제대로 이루어져야 합니다.

402 Payment Required

해당 응답코드는 거의 사용되지 않으며 표준 규칙도 존재하지 않습니다.

해당 코드의 초기 목적은 디지털 결제 시스템에 사용되는 것입니다.

403 Forbidden

클라이언트가 콘텐츠에 대한 엑세스 권한이 없을 때 사용하는 응답코드입니다.

401과 다른 점은 클라이언트에 대한 인증은 이루어져있지만 단순 권한이 없는 경우에 사용된다는 점입니다.

404 Not Found

요청한 리소스를 찾을 수 없을 때 사용하는 응답코드입니다.

보통 URL이 잘 못 되었을 경우 볼 수 있는 응답코드이지만 다음과 같은 예시에서도 사용될 수 있습니다.

1. 서버의 Endpoint는 유효하지만 리소스 자체가 존재하지 않는 경우
2. 권한이 없는 클라이언트로부터는 리소스의 존재를 숨겨야 하는 경우

위 두가지의 예시상황에 대해 API 개발 시 적용해보는 것도 좋을 것 같습니다.

405 Method Not Allowed

쉽게 설명하면 서버에서는 해당 Endpoint에 대해 GETMapping만 되어있는데, 클라이언트 측에서 POST로 요청을 보낼 때 사용하는 응답코드입니다.

다음은 5번 Server Error Responses에 대해서는 주로 사용하는 500 Code만 알아보겠습니다.

 

---

Server error responses (500 – 599)

서버 사정으로 메시지 처리에 문제가 발생한 경우입니다.

서버의 부하, DB 처리 과정 오류, 서버에서 Exception이 발생하는 경우를 의미합니다.

500 Internal Server Error

서버에 처리 방법을 알 수 없는 상황이 발생할 때 사용하는 응답코드입니다.

주로 예외가 발생할 때 사용하는 응답코드로써 API개발 시 SQLException등과 같은 상황에서 클라이언트에게 전달하는 코드로 사용합니다.

 

501 Not Implemented

클라이언트 요청 URL에 대해 서버가 아직 메서드를 구현하지 않음을 나타낼 때 사용하는 응답코드입니다.

 

 

---

정리

이번 포스팅을 하게 된 계기는 API 개발 중 예외처리를 하는 과정에서 xx같은 예외에 대해서는 어떤 Status Code를 응답으로 주어야 하는지, yy같은 예외에 대해서는 또 어떻게? 라는 고민을 가지면서 Status Code에 대해서 한번 정리할 겸 MDN 레퍼런스를 참조하여 살펴보는 과정에서 작성하게 되었습니다.

 

HTTP Status Code에 대해 정리하는 시간을 가지면서 제 나름대로의 백엔드 API 개발 방향성을 좁힐 수 있었습니다.

처음 고민은 과연 API단에서 Error, 즉 서버에서 예외가 발생했을 경우 클라이언트에게 어떤 응답을 보내주어야 하나에 대한 고민이였습니다.

처음 생각은 에러의 종류(원인분석)에 대한 개별 Status Code를 전달해야하는게 맞지 않나 라는 생각이였지만 500 Internal Server Error Code와 함께 보내는 데이터에 에러의 원인을 명시하는것도 좋은 방법이겠구나 생각해 봅니다.

 

좋은 시간이였습니다 :)

 

---

Reference

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

HTTP response status codes - HTTP | MDN