GET

사용법

GET 요청은 서버 상태를 변경하지 않고 데이터를 가져옵니다. 요청 본문에 담긴 내용에는 일반적으로 정의된 의미가 없으며, 질의 전체는 대상 URI와 헤더로 표현됩니다. 응답은 기본적으로 캐시 가능하므로 GET은 웹 캐싱의 토대가 됩니다.

GET은 탐색, 링크 클릭, 그리고 method 속성이 없는 폼 제출에서 브라우저의 기본 메서드입니다.

HTTP 명세가 GET 요청의 본문을 금지하지는 않지만, 그러한 본문의 의미는 정의되어 있지 않습니다. 브라우저와 Fetch API는 GET 요청 본문을 제거합니다. 많은 서버와 프록시가 이를 무시하거나 거부합니다. GET 요청의 본문에 의존하는 것은 상호운용성 측면에서 안전하지 않습니다.

특성

GET은 안전하고 멱등하므로, 같은 요청을 여러 번 보내도 결과가 같고 리소스를 변경하지 않습니다. 브라우저, 크롤러, 프록시 모두 이 보장에 의존합니다.

조건부 GET

If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since, If-Range 중 하나 이상의 검증자 헤더가 있으면 GET 요청은 조건부가 됩니다. 서버는 조건을 평가하여 조건이 충족될 때만 표현 전체를 반환합니다.

부분 GET

Range 헤더를 포함하면 GET이 부분 요청으로 바뀝니다. 서버는 요청된 바이트 범위만 206 상태와 함께 반환합니다. 416 상태는 그 범위를 충족할 수 없음을 나타냅니다. 범위 요청을 지원하지 않는 서버는 본문 전체와 함께 200을 반환합니다.

부분 GET은 중단된 다운로드를 재개하거나 대용량 파일을 구간별로 스트리밍하는 데 유용합니다.

기본 GET

최소한의 GET 요청은 루트 리소스를 가져옵니다. 서버는 표현 전체와 함께 200을 반환합니다.

요청

GET / HTTP/1.1
Host: example.com

응답

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1256

<!doctype html>
<html>...

조건부 GET

이 요청에는 If-Modified-Since가 포함되어 있으므로, 서버는 지정된 날짜 이후 리소스가 변경된 경우에만 본문을 반환합니다. 변경되지 않은 리소스는 본문 없이 304를 내놓습니다.

요청

GET / HTTP/1.1
Host: example.com
If-Modified-Since: Sat, 01 Jan 2022 12:00:00 GMT

응답(변경 없음)

HTTP/1.1 304 Not Modified
ETag: "abc123"

부분 GET

Range 헤더는 처음 512바이트만 요청합니다. 서버는 206과 함께, 반환한 구간을 나타내는 Content-Range 헤더로 응답합니다.

요청

GET /file.bin HTTP/1.1
Host: example.com
Range: bytes=0-511

응답

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-511/8192
Content-Length: 512

CORS

GET은 CORS 안전 목록에 포함된 메서드입니다. 교차 출처 GET 요청은 프리플라이트 요청을 유발하지 않으므로, 브라우저에서 교차 출처 리소스를 가져올 때 GET이 기본 메서드가 됩니다.

GET과 POST 비교

GET은 데이터를 가져옵니다. POST는 처리할 데이터를 제출합니다. GET 매개변수는 URL 쿼리 문자열에 실려 가고, POST 매개변수는 요청 본문에 들어갑니다.

GET 응답은 캐시할 수 있고 북마크할 수 있습니다. POST 응답은 명시적인 신선도 정보가 있을 때만 캐시할 수 있습니다. URL에는 실질적인 길이 제한이 있어 GET이 실어 나르는 데이터 양이 제한됩니다. POST에는 실질적인 본문 크기 제한이 없습니다.

GET은 안전하면서 멱등합니다. POST는 둘 다 아닙니다. GET을 반복하면 같은 결과가 돌아옵니다. POST를 반복하면 리소스가 중복 생성되거나 처리가 두 번 일어납니다.

GET과 POST 사이의 성능 차이는 무시할 수준입니다. 선택은 작업의 성격에 달려 있습니다. 조회에는 GET을, 제출에는 POST를 사용합니다.

보안

GET 매개변수는 URL, 브라우저 기록, 서버 로그, Referer 헤더에 그대로 드러납니다. 비밀번호, 토큰, 개인 식별 정보 같은 민감한 데이터는 절대 쿼리 문자열에 나타나서는 안 됩니다.

GET 요청은 GET을 자동으로 유발하는 와 태그를 통해 CSRF 공격에 더 많이 노출됩니다. POST 역시 적절한 토큰이 없으면 CSRF에 취약합니다.

GET도 POST도 그 자체로는 암호화를 제공하지 않습니다. 전송 중 데이터를 보호하려면 HTTPS가 필요합니다.

SEO 영향

검색 엔진은 GET으로 크롤링합니다. Googlebot을 비롯한 크롤러는 GET으로 페이지를 가져와 색인하므로, 리소스는 평범한 GET에 응답할 때만 발견될 수 있습니다. 캐시 가능하고 멱등한 GET 응답이 가장 효율적으로 크롤링되는데, 크롤러가 ETag나 Last-Modified 같은 검증자를 재사용해 변경되지 않은 페이지의 재수집을 건너뛰기 때문입니다.