1] GET

GET Method는 대상 리소스에 대한 현재 선택된 representation의 전송을 요청한다.

성공적인 응답은 대상 URI가 식별한 동일성의 품질을 반영한다.(계속 요청하면 항상 동일한 응답을 줌)

따라서 HTTP를 통해 식별 가능한 정보를 검색하는 것은 일반적으로 GET 요청을 통해 수행되며 200(OK) 응답을 준다.

리소스 식별자를 원격 파일 시스템 경로명으로, representation을 해당 파일 콘텐츠의 복사본으로 생각하기 쉽고 실제로 그렇게 구현되는 리소스가 많으나 실제로 이러한 제한은 없다.

리소스 식별자를 원격 파일 시스템 경로명으로 적용한 예시

http://www.example.com/images/logo.png

images 디렉토리 안의 logo.png 파일

리소스에 대한 HTTP interface가 어떻게 되어 있든 각 리소스 식별자가 구현에 어떻게 대응하는지, 어떻게 해당 구현이 대상 리소스의 현재 표현을 선택하고 전송하는지는 origin server가 알면 된다.

클라이언트는 요청에 Range header fields를 전송하여 선택한 표현의 일부만 전송하도록 요청하는 range request로 GET의 의미를 변경할 수 있다.

비록 request message framing이 사용되는 method와 무관하지만, GET 요청에서 수신되는 콘텐츠에는 일반적으로 정의된 의미가 없고 request의 meaning이나 target을 변경할 수 없으며, 일부 구현에서는 request smuggling attack(여러 수신자 간의 protocol parsing에서의 차이를 악용하여 겉보기에는 무해한 요청 내에 추가 요청을 숨기는 기법)의 가능성 때문에 요청을 거부하고 연결을 끊을 수 있다.

client는 대역 안 또는 밖에서 해당 요청에 목적이 있고 적절하게 지원될 것임을 사전에 밝힌 origin server에 직접 요청하지 않는 한 GET 요청에서 content를 생성해서는 안된다.(GET 요청에 Body를 실어 보내면 안된다.)
origin server는 HTTP 통신 참여자가 request chain의 중개자(intermediaries)를 알지 못하는 경우가 많으므로 content를 수신하기 위해 private agreements에 의존해서는 안 된다.

웹 브라우저가 웹 페이지를 요청할 때, 중간에 프록시 서버가 있는지, 캐시 서버가 있는지 알 수 없다.(request chain의 intermediaries)
마찬가지로, 웹 서버도 자신의 웹 페이지를 요청한 브라우저가 직접 연결된 것인지, 아니면 프록시 서버를 거쳐서 연결된 것인지 알 수 없다.

따라서 표준 규약에서 벗어난 방식(웹 브라우저와 웹 서버 사이의 특별한 약속**,** private agreements) HTTP 통신에 참여하는 다른 중개자(프록시 서버, 캐시 서버 등)가 이해하지 못할 수 있기 때문에, 모든 HTTP 통신에서 주의해서 사용해야 한다.

GET 요청에 대한 응답은 캐시가 가능하며 캐시는 Cache-Control header field에 달리 지정하지 않는 한 후속 GET 및 HEAD requests를 충족하는 데 사용할 수 있다.

query fields와 같이 GET으로 정보 검색을 수행하는 경우 민감한 데이터가 제공될 수 있다. 이러한 경우에는 정보를 드러내지 않도록 데이터를 필터링하거나 변형할 수 있다. 특히 응답을 캐싱하여 얻는 이점이 없을 경우, GET 대신 POST 메서드를 사용하면 target URI 안이 아닌 request content에 해당 정보를 전송할 수 있다.

1. Representation

Representation은 프로토콜을 통해 쉽게 통신할 수 있는 format으로 특정 리소스의 과거, 현재 또는 원하는 상태를 반영하도록 의도된 정보이다.

Representation은 representation metadata 세트와 잠재적으로 무한한 representation data의 stream으로 구성된다.

target resource는 리소스의 현재 상태를 반영하기 위해 각각 의도된 여러 개의 표현을 제공받거나 생성할 수 있다.
일반적으로 content negotiation에 기반한 알고리즘을 사용하여 이러한 representation 중 주어진 request에 가장 적합한 representation을 선택한다.
이러한 selected representation은 conditional requests를 평가하고 200(OK), 206(Partial Content) 및 304(Not Modified) GET 응답에 대한 콘텐츠를 구성하기 위한 데이터 및 메타데이터를 제공한다.

응답이 성공 또는 오류를 나타내는 content를 전달할 때, origin server는 해당 정보를 다른 format, 언어, encoding 등 다양한 방식으로 표현하는 경우가 많다.

따라서 HTTP는 content negotiation을 위한 메커니즘을 제공한다.

1) Representation data

HTTP message와 연관된 representation data는 메시지의 content으로 제공되거나 message semantics와 target URI에 의해 참조된다.

representation data의 데이터 유형은 header fields의 Content-Type과 Content-Encoding에 의해 정해진다.

2) Representation metadata

Representation header fields는 representation에 대한 metadata를 제공한다.

메시지에 content가 포함되어 있으면 representation header fields는 해당 데이터를 해석하는 방법을 설명한다.(위와 같이 어떤 content-type인지, 어떤 content-encoding을 사용하는지)

동일한 GET 요청과 HEAD 요청이 있을 때, GET 요청의 응답은 representation data(content)를 포함해서 주지만, HEAD 요청의 응답은 representation data를 주지 않고 그 representation data를 설명하는 representation header fields만 준다.

---

Next Plan

Range에 대한 설명 추가

---

References

https://www.rfc-editor.org/rfc/rfc9110.html

https://www.baeldung.com/cs/http-get-with-body