📌  2XX Success

✅ 200 OK

상태는 코드 요청이 성공했음을 나타낸다. 200의 응답에서는 요청 메서드에 따라서 전달되는 내용이 다르다.

  • Get : 리소스를 가져왔고 메시지 바디에서 리소스를 확인할 수 있다.
응답:
HTTP/1.1 200 OK
Content-Type: application/json

{
    "id": 123,
    "name": "John Doe",
    "email": "john@example.com"
}
  • Post: 동작의 상태 또는 그 결과를 확인할 수 있다. (Get과 응답 형태는 동일하지만 요청이 다름.)
응답: 
HTTP/1.1 200 OK
Content-Type: application/json

{
     "id": 124,
     "name": "Jane Doe",
     "email": "jane@example.com"
}
  • Head:  대상 리소스를 반환하지만, Body에 표현 데이터를 반환하지 않고 헤더에 메타 데이터를 반환한다.
응답:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 85
  • Put: 동작의 상태 (Post 또는 Get과 유사하다, 근데 요청 형태가 다름)
응답:
HTTP/1.1 200 OK
Content-Type: application/json

{
    "id": 123,
    "name": "John Doe",
    "email": "john@example.com"
}
  • Delete: 요청으로 수행된 동작의 상태를 반환
응답:
HTTP/1.1 200 OK
Content-Type: text/plain

User 123 successfully deleted.
  • Option : 대상 리소스가 지원하는 통신 옵션을 알려준다
응답:
HTTP/1.1 200 OK
Allow: GET, POST, OPTIONS
  • Trace : 서버가 받은 요청 메시지가 바디에 들어가 있음.
응답:
HTTP/1.1 200 OK
Content-Type: message/http

TRACE /users HTTP/1.1
Host: example.com

 

참고(공식 문서): 

메시지 Body에 대한 내용:

CONNECT 메서드에 대한 응답을 제외하면, 200 응답은 메시지 콘텐츠를 포함해야 합니다. 단, 메시지 구조(message framing)가 명시적으로 콘텐츠 길이가 0이라고 표시된 경우는 예외입니다

만약 요청의 어떤 측면에서 성공 시 콘텐츠가 필요 없다는 선호가 나타난다면, 서버는 대신 204 (No Content) 응답을 보내야 합니다. CONNECT 메서드에서는 성공한 결과가 즉시 시작되는 터널(tunnel)이므로 콘텐츠는 포함되지 않습니다.

 

사실, Connect 말고도 Head 같은 경우도 메시지 Body가 존재하지 않는데(위의 예시를 보면) Connect는 명시적으로 바디가 없도록 설계되었고 Head는 전송되지 않도록 설계되었다는 점에서 Connect가 매우 특수한 작동 방식 때문에 명세서에서 언급이 된 것으로 생각됩니다. 따라서 대부분의 경우에 Body가 필요 없는 경우에는 204를 쓰도록 명시하고 있습니다

 

캐시에 대한 내용: 

200 응답과 캐싱 200 응답은 휴리스틱(경험적)으로 캐싱 가능합니다. 이는 메서드 정의나 명시적 캐시 제어(캐싱 사양의 Section 4.2.2 참조)에 의해 달리 명시되지 않는 한 캐싱이 가능함을 의미합니다.

GET 또는 HEAD에 대한 200 응답 GET 또는 HEAD 요청에 대한 200 응답에서, 원(origin) 서버는 선택된 표현(representation)에 대해 가능한 검증자 필드(validator fields)(사양 Section 8.8 참조)를 제공해야 합니다.선호되는 검증자 필드는 **강력한 엔터티 태그(strong entity tag)**와 Last-Modified 날짜입니다. 상태 변경 메서드에 대한 200 응답 상태 변경 메서드(예: PUT, POST, DELETE)에 대한 200 응답에서는, 응답에 포함된 검증자 필드는 성공적으로 요청 의미를 적용한 결과로 형성된 **새로운 표현(new representation)**에 대한 현재 검증자를 나타냅니다.

 

명시적으로 캐시를 선언하지 않는 이상 200 응답은 캐싱으로 사용될 수 있다고 한다. 캐싱과 관련된 개념으로 검증자 필드가 사용되는데, 가장 선호되는 E-tag와 Last Modified를 반환하고 캐싱에 이용하도록 설명하고 있다. 간단히 설명하면 검증자 필드를 이용해서 리소스가 바뀐지 확인하고 바뀌지 않았다면 리소스를 새로 요청하지 않고 캐시에 가지고있는 리소스를 사용하는 것으로 알고 있다. 

✅ 201 Created

새로운 리소스가 성공적으로 생성이 되었다는 응답입니다. 당연히 생성된 리소스에 대한 응답이기 떄문에 Post 또는 Put 매서드의 응답으로 사용되는 경우가 많다.

💡 200번 에러와 다른점은, Location이 표시된다는 점입니다. 크게 다른 점은 없으나 새로운 리소스를 생성하는 작업에서는 조금 더 많은 정보를 주고 있기 때문에 좀 더 정확한 특징이 있습니다. 또한 캐시와 관련 기능이 공식 문서에 나와있어서 200번으로 캐시 관련 작업을 하게 된다면 내용을 추가하겠습니다.

 

참고(공식 문서):

요청에 의해 생성된 주요 리소스는 응답에 포함된 Location 헤더 필드나, Location 헤더가 없을 경우 요청의 대상 URI를 통해 식별됩니다.

201 응답에는 일반적으로 생성된 리소스에 대한 설명과 링크가 포함됩니다. 또한, 응답에 포함된 검증자 필드(Section 8.8)는 요청을 통해 생성된 새로운 리소스의 현재 검증자를 전달합니다. 하지만 PUT 메서드(Section 9.3.4)는 추가 요구사항이 있어 이러한 검증자를 포함하지 않을 수도 있습니다.

 

리소스가 수정될 경우 수정된 리소스에 대한 새로운 검증자를 전달하는 기능이 있다고 설명하고 있습니다. 

 

✅ 203 Non-Authoritative Information

헤더에 들어있는 정보가 원래 서버가 아닌 프록시의 사본에서 와서 신뢰 할 수 없는 정보를 의미웹사이트가 프록시 서버(CDN 또는 VPN 또는 기타)를 사용할 때 반환되는 상태 코드입니다. 203 (Non-Authoritative Information) 상태 코드는 요청이 성공적으로 처리되었음을 나타내지만, 포함된 내용은 원본 서버의 200 (OK) 응답과 다르게 변형 프록시에 의해 수정된 상태임을 의미합니다.

 

  • 203 응답 또한 캐시가능합니다.

✅ 204 No Content

성공했는데 Body에 넣어서 보낼 것이 없는 경우 사용됩니다. 예를 들어 웹문서 편집기에서 저장 버튼이나 삭제 버튼 같은 경우 따로 응답을 할 필요가 없기 때문에 204를 사용합니다. 

 

참고(공식 문서):

예를 들어, PUT 요청에 대해 204 상태 코드를 받았다면, 작업이 성공적으로 완료되었으며 새로운 데이터를 나타내는 엔터티 태그가 포함된 ETag 필드가 함께 제공될 수 있습니다.

204 응답은 사용자가 현재 문서를 유지하면서 작업 성공을 알릴 수 있도록 돕습니다. 예를 들어, 문서를 저장하는 작업이 끝난 후에도 계속해서 문서를 수정할 수 있게 해주는 방식입니다. 자동화된 데이터 전송이 필요한 시스템에서도 자주 사용됩니다.

204 응답은 콘텐츠나 트레일러가 포함될 수 없으며, 캐싱이 가능하다는 점도 특징입니다.

 

201에서 Body에 대한 내용을 설명했는데 Connect를 제외하고 Body가 필요가 없다면 204를 사용한다고 명시되어 있습니다. 추가적으로 캐싱과 관련된 내용이 포함되어 있습니다.

✅ 205 Reset Content

클라이언트에게 브라우저를 새로 고침하라는 의미를 전달한다. 

 

참고(공식 문서):

사용자가 데이터를 입력하는 경우에 사용되며, 입력된 데이터를 제출한 후 다음 입력을 쉽게 시작할 수 있도록 데이터를 초기 상태로 되돌리는 경우에 사용됩니다.

예를 들어, 사용자가 양식(form), 메모장(notepad), 캔버스(canvas) 등에서 데이터를 입력하고 제출한 후, 다시 초기 상태로 되돌려 새로운 입력을 시작할 수 있도록 하는 경우입니다.따라서 205 상태 코드 응답에서는 추가적인 콘텐츠가 제공되지 않으며, 서버는 205 응답에서 콘텐츠를 생성해서는 안 됩니다.

 

✅ 206 Partial Content

클라이언트가 리소스의 일부 혹은 특정 부분을 요청했을 때 사용된다. 예를 들어, 클라이언트가 파일의 일부를 다운로드하거나, 특정 범위만 요청했을 때 서버는 206 상태 코드와 함께 해당 부분만 응답한다.

 

주로 용량이 큰 이미지나 동영상같은 파일을 요청하였을 때, 아직 완전히 로드 되지 않았음에도 특정 범위에 대한 요청을 할때 쓰인다. 그러면 서버는 전체 파일 대신 요청된 범위만 반환한다.

 

참고(공식 문서):

Content-Length 헤더 필드는 206 응답의 콘텐츠 크기를 나타내며, 이는 선택된 표현의 전체 길이와는 다를 수 있습니다. 각 Content-Range 헤더 필드는 선택된 표현의 전체 길이에 대한 정보를 제공합니다.

 

응답 예시:
HTTP/1.1 206 Partial Content
Content-Range: bytes 0-199/1000
Content-Length: 200
Content-Type: text/plain

Hello, this is a partial response.

 

Range를 통해서 전체 길이와 현재 어디까지 전송이 되었는지 확인하여 추가적인 요청이 필요한지 확인할 수 있다.

✅ 207 Multi-Status

여러 응답이 함께 있는 경우를 나타낸다. 207을 통해서 여러 응답들을 한번에 처리할 수 있다. 해당 코드는 WebDAV(Web Distributed Authoring and Vesioning)에 이용되는데 XML로 구성된 여러개의 응답을 포함할 수 있다.

 

응답 예시:
<?xml version="1.0" encoding="UTF-8"?>
<statuses>
  <status>
    <code>200</code>
    <message>Resource retrieved successfully.</message>
    <resource>
      <id>1</id>
      <name>Resource 1</name>
    </resource>
  </status>
  <status>
    <code>201</code>
    <message>Resource created successfully.</message>
    <resource>
      <id>2</id>
      <name>Resource 2</name>
    </resource>
  </status>
  <status>
    <code>204</code>
    <message>Resource deleted successfully.</message>
  </status>
</statuses>

 

예를 들어서 3개의 작업에 대한 응답을 다음과 같이 한번에 처리할 수 있다.

 

✅ 208 Already Reported

해당 코드 또한 WebDAV(Web Distributed Authoring and Vesioning)에 이용된다. <dav:propstat> 응답 요소 내에서 사용되며, 동일한 컬렉션에 대한 여러 바인딩에 대해 내부 멤버를 반복해서 열거하지 않도록 하기 위해 사용된다.

 

즉, 여러 바인딩이 동일한 컬렉션에 연결되어 있을 때, 각각의 바인딩에 대해 내부 멤버를 여러 번 나열하지 않기 위해 사용된다. 이미 응답을 한 내용이기 때문에 중복해서 다시 표기하기 보다는 앞에서 알려준 응답을 사용하라는 뜻이다.

 

응답 예시:

첫번째 응답
<D:propstat>
  <D:prop>
    <D:displayname>My Collection</D:displayname>
    <D:resourcetype>
      <D:collection/>
    </D:resourcetype>
  </D:prop>
  <D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>

두번째 응답:
<D:propstat>
  <D:prop>
    <D:getlastmodified>Wed, 31 Dec 2024 23:59:59 GMT</D:getlastmodified>
  </D:prop>
  <D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>

두 번째 응답은 컬렉션의 마지막 수정 시간을 나타내며, 이 정보를 통해 최종 수정된 상태의 컬렉션을 가져오라는 의미입니다.

✅ 226 IM Used

IM(Instance Manipulation) 즉, 인스턴스 조작이 이루어졌다는 의미이다. 서버의 Get 요청에 대한 조작이 성공적으로 반영이 되었다는 뜻이다.  HTTP Delta Encoding이라는 기법을 사용하면 반환되는 상태 코드라고 한다.

 

HTTP Delta Encoding이란, 서버가 클라이언트에게 이전 상태와의 차이만을 전송하여 데이터를 효율적으로 전달하는 방법입니다. 즉, 클라이언트가 요청한 리소스에 대한 변경 사항만을 전달하여 전송 데이터의 크기를 줄이는 방식입니다.

사용 예시:
웹 애플리케이션에서 이미지를 업데이트하거나, 콘텐츠를 수정할 때 전체 리소스를 다시 전송하는 대신, 이전 상태와의 차이만 전송하여 데이터 크기를 줄일 수 있습니다.파일 시퀀스, 문서 수정 버전 관리 등에서 주로 사용됩니다.

 

 

Reference:

강의 - 모든 개발자를 위한 Http 기본 지식 - 김영한 🔗 

티스토리 - Http 상태 코드 총 정리판 1XX~5XX - Inpa 🔗

공식 문서 - RCF 9110 🔗

공식 문서 - MDN Web Docs 🔗

'Server' 카테고리의 다른 글

CI/CD 도구 - 1.Github Action  (1) 2025.03.21
HTTP 메서드를 알아보자  (0) 2025.01.03

티스토리툴바