🌐 2XX (Successful) 상태 코드

...

2XX Success

2xx 번대의 상태 코드들은 요청이 정상적으로 처리되었다는 의미를 가진다.

단순히 요청에 대한 성공을 나타내지만, 클라이언트가 어떠한 행위에 대한 성공인지에 대한 것을 나타내기 때문에, 응답을 받고 클라이언트가 취할 행위를 결정하는데 중요하면서도 정말 자주 보게될 상태 코드일 것이다.

200 OK

OK ⇢ 클라이언트의 요청을 서버가 정상적으로 처리
메세지 바디에는 HTTP 메서드에따라 각기 다른 요청된 리소스를 포함
- ~~GET~~ : 리소스를 가져왔고 메시지 바디에 들어있음
- ~~POST~~ : 리소스가 명시하는 행동의 결과가 메시지 바디에 들어있음
- ~~PUT~~ : 200 OK (수정 완료) / 201 Created (수정할 개체가 없어 새로 업로드)
- ~~DELETE~~ : 200 OK (삭제 완료) / 204 No Content (삭제할 개체가 없을때)
- ~~HEAD~~ : 개체 헤더가 메시지 바디에 들어있음
- ~~TRACE~~ : 최종 서버가 요청받은 메시지가 바디에 들어있음
200 응답은 캐쉬될 수 있다.

📍 200 상태코드 흐름 예시

클라이언트에서 '/members/100' 리소스를 GET 으로 요청
서버에서 그에 대한 응답을 성공적으로 보내면서 200 OK 의 상태코드를 함께 전송
응답 메세지 바디에는 HTTP 메서드 요청에 대한 응답 데이터(username, age)가 들어있음

201 Created

Created ⇢ 클라이언트의 요청을 서버가 정상적으로 처리했고 새로운 리소스가 생김
응답 헤더에는 생성된 리소스에 대한 설명과 링크를 제공
201 상태 코드는 POST, PUT 요청에 대한 응답에 주로 이용된다.
- POST : 개체를 새로 생성
- PUT : 만일 수정할 개체가 없으면 새로 생성

클라이언트의 요청이 성공적으로 이뤄졌다는 의미 자체는 200과 동일한데, 성공과 동시에 새로운 리소스가 생성되었다는 의미를 포함한다는 점에서 차이가 있다고 보면 된다.
생성 요청에 대해 200 OK로 응답해도 되긴 하지만, 객체를 생성하는 요청에 대해서 서버는 반드시 정확한 의미를 위해 해당 코드로 응답하는 것이 좋다.

📍 201 상태코드 흐름 예시

클라이언트가 '/members' 컬렉션에 POST 로 신규 리소스를 생성하는 요청을 전달
서버가 신규 리소스를 성공적으로 생성한 뒤 201 Created 상태코드를 담아 전송
1. ~~Location~~ / ~~Content-Location~~ 헤더 : 생성된 리소스에 대한 참조 URL
2. 메세지 바디에는 새로 생성된 데이터가 들어있음

202 Accepted

Accepted ⇢ 클라이언트의 요청은 정상적이나, 서버가 아직 처리를 완료하지 못해서 일단 알았다는 표시
보통 요청이 정상적이면 작업의 성공/실패로 알려주는 것이 일반적이나, 요청 처리 자체가 무거워 오래 걸릴경우 비동기로 처리하여 완료되면 나중에 알려주겠다는 의미이다.
응답 본문에는 요청에 대한 상태와 요청의 처리가 언제 완료될 것인지에 대한 추정(혹은 그에 대한 정보를 어디서 얻을 수 있는지)을 포함해야 한다.

👌 202 상태코드 이해하기

202 상태 코드를 보다 이해하기 위해 맥도날드에서 햄버거를 주문하는 프로세스 실생활 예시를 들어볼 수 있다.

고객(클라이언트)은 카운터 직원(URI)에게 햄버거 주문(HTTP Request)를 한다.
그러면 주문 요청을 받은 직원이 해당 주문을 주방장에게 전달한다.
주방장은 햄버거를 만들기 시작한다. (비동기)
직원은 번호표(자원 식별자)를 고객에게 주고(202 응답) 다음 고객의 주문을 받는다.

즉, 단순히 요청이 성공적으로 접수되었다는 의미로 번호표를 주듯이 202 상태코드를 사용했다라고 이해하면 된다.

그러면 비동기로 처리되는 작업(햄버거가 다 만들어짐)의 완료 여부는 언제 확인할까?

클라이언트가 요청의 완료 여부를 확인할 수 있는 방법은 Callback 과 Polling 두 가지가 있다.

콜백(Callback)은 서버가 작업이 완료되면 알아서 클라이언트에게 알려주는 것이다. 햄버거가 만들어지면 직원(Callback)이 번호(자원 식별자)를 부르고 고객은 햄버거를 받아간다.
폴링(Polling)은 클라이언트가 주기적으로 해당 작업의 처리 상태를 조회하는 것이다. 고객은 번호표(자원 식별자)를 들고 직원(Polling)에게 가서 햄버거 주문이 완료되었는지 일정 시간마다 물어보고 완료되면 햄버거를 받아간다.

📍 202 상태코드 흐름 예시 (Polling)

1. 클라이언트는 서버에 XML 데이터를 게시하기 위해 POST 요청 한다.

2. 서버는 요청이 승인되었고 아직 처리중이라 202 응답을 한다.

3. 클라이언트가 GET 요청을 한다.

4. 서버는 아직 처리가 되어있지 않기 때문에 현재 상태 요청에 대한 응답을 한다. (똑같이 202)

3. 클라이언트가 재차 GET 요청을 한다.

4. 요청 처리가 완료된 서버는 상태 요청에 대한 200 성공 응답을 한다.

5. 클라이언트는 200 상태 코드를 수신한 후 폴링을 중지하고 그에 따라 조치를 취한다.

203 Non-Authoritative Information

Non Authoritative Information ⇢ 헤더에 들어있는 정보가 원래 서버가 아닌 프록시의 사본에서 와서 신뢰 할 수 없는 정보를 의미
웹사이트가 프록시 서버(CDN 또는 VPN 또는 기타)를 사용할 때 반환되는 상태 코드
즉, 요청은 성공했지만 payload가 원본 서버의 200(OK) 응답이 변환 프록시에 의해 수정되었음을 나타낸다.
프록시가 리소스의 사본을 갖고 있지만, 리소스에 대한 메타 정보(헤더)를 검증하지 못한(혹은 안 한) 경우 이런 일이 발생할 수 있다.
단, 203(신뢰 할수없는 정보) 상태 코드 대신 214(변환이 적용된 경고) 사용을 권장한다.

204 No Content

No Content ⇢ 클라이언트의 요청은 정상적이다. 하지만 제공할 컨텐츠가 없다.
서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 담을 데이터가 없음을 의미한다.
절대적인 것은 아니지만 다음 메서드에 사용될 수 있다.
- ~~POST~~ : 데이터 추가 요청을 하고 데이터 응답은 필요없을때
- ~~PUT~~ : 자원 수정 요청의 결과가 동일하여 변경된 내용이 없을 때
- ~~DELETE~~ : 삭제할 자원이 없어 응답이 무의미 할때 (처리 자체는 성공이니 2XX 번대 이지만 자원이 삭제되지는 않았으니 이런 애매모호한 상황에 사용)
이런 모호성 때문에 204 코드를 사용하는 HTTP API는 흔하지 않다.
204 응답은 기본적으로 캐시할 수 있다.

📍 204 상태코드 흐름 예시

204를 이해하는 좋은 예로는 문서 편집기의 SAVE 버튼을 들 수 있다. 현재까지 작성한 내용을 저장만 하고 별다른 응답 데이터를 받을 필요가 없고 페이지 전환도 필요가 없기 때문에, 서버는 SAVE 의 결과로 어떠한 데이터도 전송해줄 필요가 없다.

주의할 점은 200으로 응답하고 body에 ~~null~~, {}, [] 등으로 빈 데이터로 응답하는 것과 다르다는 것이다. 204의 경우 아예 HTTP 응답 body가 존재하지 않는 경우다.

205 Reset Content

Reset Content ⇢ 브라우저를 새로 고침하라는 의미
현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우거나, 캔버스 상태를 재설정하거나 할때, 브라우저에게 화면의 UI를 새로 고치도록 지시한다.
브라우저를 위해 사용되는 코드라고 보면 된다.
PUT 메서드 동작과 함께 이용될 수 있다.

206 Partial Content

Partial Content ⇢ 요청된 리소스가 성공적으로 검색되었지만 리소스 범위의 일부만 반환되고 있음을 나타냄
이미지나 동영상같은 대용량 미디어 파일을 요청하였을 때, 아직 완전히 로드 되지 않았음에도 특정 범위에 대한 요청을 할때 쓰인다. 그러면 서버는 전체 파일 대신 요청된 범위만 반환한다.
대용량 파일을 조각으로 다운로드하거나 미디어 파일을 스트리밍할 때 유용할 수 있다.
클라이언트에서 ~~Range~~ 헤더를 통해 이 상태 코드를 응답 받을 수 있다.

📍 206 상태코드 흐름 예시

사용자가 웹 사이트에서 대용량 동영상 파일을 다운로드 한다고 가정해 보자. 그런데 이 경우 파일 자체가 크기 때문에 다운로드 프로세스에 시간이 걸리므로, 클라이언트는 파트별로 나누어서 범위 요청/응답 받으려고 한다. (스트리밍)

1. 클라이언트는 해당 경로로 GET 요청을 보낸다. 이때 ~~Range~~ 헤더를 통해 예상 범위를 알린다.

2. 서버는 현재 다운로드된 범위에 대한 응답을 해준다.

응답에는 ~~Content-Range~~와 ~~Date~~ 헤더를 반드시 포함해야 하며, ~~Etag~~와 ~~Content-Location~~중 하나의 헤더도 반드시 포함해야 한다.
~~Content-Range: bytes 0-1023/2048~~ : 여기서 2048는 전체 파일의 총 길이(바이트)이고, 0-1024은 처리가 완료된 부분 영상 데이터인 바이트 범위이다.
만일 여러 콘텐츠 범위를 포함하는 경우 다음 예와 같이 각 범위를 쉼표로 구분하여 지정할 수 있다. ~~Content-Range: bytes 0-500/1234, 1000-1500/1234~~

3. 클라이언트는 두 번째 요청을 다시 보내고 서버에 ~~Range~~ 헤더를 사용하여 남은 예상 범위를 알린다.

4. 서버는 이에 대한 응답을 해준다.

207 Multi-Status

Multi Status ⇢ 여러 응답이 혼합되어 있을때 나오는 상태코드
즉, 요청이 다양한 리소스에 대한 여러개의 응답을 207 Multi Status 를 통해 한번에 처리하는 것으로 보면 된다.
이 여러개의 응답은 기본적으로 XML로 이루어져 있어, 하위 요청 수에 따라 여러개의 개별 응답 코드를 포함할 수 있다. (JSON으로도 응답 설정이 가능)
해당 코드는 WebDAV(Web Distributed Authoring and Vesioning)에 이용된다.

[ WebDAV 란? ]

WebDAV(Web Distributed Authoring and Vesioning)는 하이퍼텍스트 전송 프로토콜의 확장으로, 웹 서버에 저장된 문서와 파일을 읽고 쓰기가 가능한 매개체로 만들어서, 편집하고 관리하는 사용자들 사이에 협업을 손쉽게 만들어 준다.

📍 207 상태코드 흐름 예시

1. 클라이언트는 XML 데이터를 서버에 게시하기위해 POST 요청한다 (단 이 작업에는 3개의 독립적인 리소스가 필요)

2. 따라서 서버는 각 리소스와의 상호 작용 결과를 표시하는 목록을 반환한다.

3. 메세지 본문을 보면, 처음 두 리소스와 상호 작용은 성공적이지만 세 번째 리소스는 잠겨 있기 때문에 오류를 보고하는 것을 알 수 있다. 이것이 성공인지 실패인지 결정하고 그에 따라 행동하는 것은 클라이언트의 몫이다.

208 Already Reported

Already Reported ⇢ 이미 앞에서 열거되었음을 의미
즉, 앞에서 이미 보고된 정보이니까, 이 정보를 다시 포함하지 않음을 의미한다고 보면 된다. 따라서 클라이언트는 이전에 제공된 데이터를 참조하면 된다.
~~PROPFIND~~ 이라는 HTTP 메서드에 대한 응답 속성으로써 쓰이며, 동일 컬렉션으로 바인드된 복수의 내부 멤버를 반복적으로 열거하는 것을 피하기 위해 사용된다.
또한 208 상태 코드는 HTTP 응답 메세지로 나타나지 않고, 페이로드 본문에만 쓰이는 특성이 있다.
해당 코드는 WebDAV(Web Distributed Authoring and Vesioning)에 이용된다.

[ WebDAV 확장 메서드 ]

~~COPY~~ - 파일을 다른 위칠 복사 시 사용한다.
~~MOVE~~ - 파일 이동 및 파일 확장자 변경 시 사용한다.
~~LINK~~ - 다른 위치로의 링크나 링크 생성 시 사용한다.
~~UNLINK~~ - LINK에 의해 생성된 링크 삭제 시 사용한다.
~~CONNECT~~ - 웹 서버에 프록시 기능을 요청할때 사용한다.
~~PROPFIND~~ - 리소스를 위한 속성을 검색한다. 웹의 파일 목록과 속성을 검색한다.
~~PROPPATCH~~ - 리소스에 대한 속성을 변경하는 메소드
~~MKCOL~~ - 컬렉션(디렉토리 , 폴더)을 생셩하는 메소드
~~LOCK~~ - 리소스에 Overwrite 방지를 위한 LOCK을 건다.
~~UNLOCK~~ - 리소스에 Overwrite 방지를 위한 LOCK을 건다.

📍 208 상태코드 흐름 예시

1. 클라이언트는 서버에게 웹의 파일 목록과 속성을 검색하는 ~~PROFIND~~ 요청을 보낸다.

2. 서버는 파일 목록이 여러개라서 위에서 배운 207 응답 코드를 수신한다.

3. 이때 각 응답에 대한 resource가 동일하기 때문에 서버는 이미 열거된 것을 인식하고 208 응답 코드를 보낸다.

218 This is fine

This is fine ⇢ 오류가 발생했지만 여긴(apache 서버) 괜찮아~ 의미
아파치(Apache) 웹 서버 에서 사용되는 비공식 HTTP 응답 코드
그래서 218 상태 코드가 수신되면, 클라이언트는 Apache 웹 서버와 통신하고 있음을 이해할 수 있다.
보통 오류 상태 코드(4XX 또는 5XX)에 대해서 클라이언트는 오류 페이지를 표시하지만, 218 응답을 이용하면 오류 페이지를 표시하지 않고 Apache가 하라는 대로 오류에 대한 행위가 변형될 수 있다.

아래 그림을 보면 더 잘 이해할 수 있을 것이다. 집(서버)가 화재(오류)가 나고 있는데 개(아파치)가 218(여긴 괜찮아) 라고 헛짓거리 하는 것으로 보면 된다.

226 IM Used

IM Used ⇢ 서버가 GET 요청에 대한 응답 의무를 다했다는 의미
즉, 요청이 현재 상태에 반용되었음을 뜻하는 것으로 보면 된다.
HTTP Delta Encoding 기법을 이용하면 반환되는 상태 코드이다.
여기서 IM은 I am 을 나타내는것이 아닌 Instance Manipulation(인스턴스 조작)의 약자이다.

📍 HTTP Delta Encoding

예를 들어 클라이언트는 서버로부터 응답받은 데이터를 브라우저에 캐시해 놓았다고 가정하자.

보통 리소스가 서버 측에서 변경된 경우, 서버는 클라이언트 측의 요청에 대해서 리소스 복사본을 캐싱해 놓았지만 수정되었기 때문에 새 리소스를 다시 보내게 된다. 하지만 수정 부분이 사소한 작은 부분일 경우, 전체 새 버전을 다시 보내는 건 어찌보면 약간 낭비 일수도 있다. 따라서 위에서 잠시 소개한 HTTP Delta Encoding 기법을 이용하면 서버가 일부 패치 형식 혹은 diff 형식의 변경 사항만 다시 보내는 식으로 처리 할수 있다. (트래픽 최적화)

만일 클라이언트가 이를 요청하고, 서버가 Delta 인코딩을 지원하는 경우 226 IM Used 상태를 사용하여 클라이언트에게 알려주게 된다. 만일 서버가 200 OK 를 보낸다면 서버가 인코딩 기능을 지원하지 않는다는 말이 된다.

[HTTP] 🌐 웹 브라우저의 Cache 전략 & 헤더 다루기

웹브라우저의 캐시(Cache) 원리 컴퓨터 운영체제에서의 캐시(Cache)는 주기억장치에서 자주 사용하는 프로그램과 데이터를 하드디스크로부터 가져오는데 시간이 많이 걸리니 캐시 저장소에 임시

inpa.tistory.com