GET

GET 메서드는 대상 리소스에 대해 현재 선택된 표현의 전송을 요청합니다. GET은 정보 검색의 기본 메커니즘이며 거의 모든 성능 최적화의 초점입니다. 따라서 사람들이 HTTP를 통해 식별 가능한 정보를 검색한다고 말할 때 일반적으로 GET 요청을 하는 것을 말합니다.

리소스 식별자를 원격 파일 시스템 경로명으로, 표현을 해당 파일 내용의 복사본으로 생각하기 쉽습니다. 실제로 많은 리소스가 그렇게 구현됩니다(관련 보안 고려 사항은 섹션 9.1 참조). 그러나 실제로는 그러한 제한이 없습니다. 리소스에 대한 HTTP 인터페이스는 콘텐츠 객체의 트리, 다양한 데이터베이스 레코드에 대한 프로그래밍 방식 보기 또는 다른 정보 시스템에 대한 게이트웨이처럼 구현될 가능성이 높습니다. URI 매핑 메커니즘이 파일 시스템에 연결된 경우에도 원본 서버는 파일을 직접 전송하는 대신 요청을 입력으로 하여 파일을 실행하고 출력을 표현으로 보내도록 구성될 수 있습니다. 어쨌든 원본 서버만 리소스 식별자 각각이 구현에 어떻게 대응하는지, 그리고 각 구현이 GET에 대한 응답에서 대상 리소스의 현재 표현을 선택하여 전송하는 방법을 알면 됩니다.

클라이언트는 요청에 범위 헤더 필드(RFC7233)를 전송하여 선택된 표현의 일부만 전송하도록 요청하는 "범위 요청"으로 GET의 의미를 변경할 수 있습니다.

GET 요청 메시지 내의 페이로드는 정의된 의미가 없으며, GET 요청에 페이로드 본문을 보내면 일부 기존 구현에서 요청을 거부할 수 있습니다.

GET 요청에 대한 응답은 캐시가 가능하며, 캐시-제어 헤더 필드에 달리 명시되지 않는 한 캐시는 후속 GET 및 HEAD 요청을 만족시키는 데 사용할 수 있습니다(RFC7234의 섹션 5.2).

HTTP 프로토콜의 GET 메서드는 디지털 사서와 비교할 수 있습니다. 그것은 데이터 자체에 변경 사항을 만들지 않고 서버에 데이터를 제시할 것을 예의 바르게 요청합니다 - 순수하게 수동적인 요청입니다.

GET 메서드가 특별한 이유는 무엇인가요?

1. 일관성: 도서관사에게 동일한 책을 여러 번 요청하는 것을 상상해보세요 - 매번 동일한 책을 받게 됩니다. GET 요청도 마찬가지로 일관되게 동일한 결과를 제공합니다.
2. 읽기만 하기: GET 요청은 관찰자의 성격을 가지고 있습니다. 데이터를 보기만 하고 변경하지 않습니다.
3. URL에서의 정보: URL을 주소나 색인 카드로 생각해보세요. 어떤 책이나 정보를 찾고 있는지를 나타냅니다. 그러나 주의: 이러한 카드에는 개인 메모가 포함되어서는 안되며, 다른 사람들이 볼 수 있습니다.
4. 빠르고 효율적인 응답: 응답을 캐시할 수 있는 능력 덕분에, GET 메서드는 반복된 요청에 대해 빠르게 응답할 수 있습니다. 이것은 각 책의 위치를 정확히 아는 잘 조직된 도서관사와 같습니다.

하지만 제한 사항도 있습니다:

1. 노트에 제한된 공간: URL에는 정보를 위한 공간이 제한적입니다. 작은 색인 카드에 쓰는 것과 같습니다.
2. 비밀이 없음: URL은 보이며 저장될 수 있기 때문에, 그것에 민감한 정보를 기록해서는 안됩니다.
3. 간섭 없음: 관찰자는 그들이 관찰하는 것에 영향을 주지 않습니다. 따라서 GET 메서드는 데이터를 수정하는 데 사용되어서는 안됩니다. 그런 일을 위해 우리의 디지털 툴박스에는 다른 도구가 있습니다.

전반적으로, GET 메서드는 디지털 공간에서 신뢰할 수 있고 필수적인 도구로서, 정보를 효율적이고 안전하게 검색하는 데 도움을 줍니다.