GET

GET은 HTTP에서 지정한 리소스의 현재 표현을 가져오도록 요청하는 메서드입니다. 웹페이지나 API 데이터를 조회할 때 사용하며, 표준상 클라이언트가 서버의 상태 변경을 요구하지 않는 읽기 목적의 요청입니다. 같은 요청을 여러 번 보내도 의도한 효과는 한 번 보낸 것과 같지만, 응답 내용이나 서버의 접속 기록까지 항상 같아지는 것은 아닙니다.

조회 대상과 응답의 관계

HTTP 명세는 GET을 대상 리소스의 현재 선택된 표현을 전송하도록 요청하는 메서드로 정의합니다. 여기서 표현은 서버가 그 리소스를 보여 주기 위해 보내는 데이터입니다. 웹페이지라면 HTML일 수 있고 API라면 JSON일 수 있습니다. GET이라는 이름이 응답을 특정 파일 형식으로 제한하거나 서버 내부의 원본 파일을 그대로 보내도록 정하지는 않습니다.

요청 대상은 주소로 지정하며, 필요한 경우 쿼리 문자열이 붙습니다. MDN의 GET 문서는 물음표 뒤에 이름과 값의 쌍으로 식별 정보를 전달하는 형태를 설명합니다. 예를 들어 목록 조회에서 특정 분류를 나타내는 값을 주소에 넣을 수 있습니다. 다만 그 이름과 값이 어떤 조건을 뜻하는지는 해당 서비스가 정하며 GET만으로 정해지지는 않습니다.

GET 요청을 보냈다는 사실과 원하는 데이터를 받았다는 사실도 구별됩니다. 서버는 요청 결과를 상태 코드와 헤더, 필요한 응답 본문으로 전달합니다. MDN의 성공 예시는 200 상태와 HTML 본문을 반환하지만, 모든 요청이 그 결과를 보장받는 것은 아닙니다. 리소스가 존재하는지, 접근이 허용되는지, 서버가 요청을 처리했는지에 따라 결과가 달라집니다.

안전성과 멱등성의 의미

GET은 표준상 안전한 메서드입니다. HTTP 명세에서 안전하다는 말은 클라이언트가 서버의 상태 변경을 요구하지 않는다는 뜻입니다. 자료를 조회하는 요청에 삭제나 주문 확정 같은 변경 작업을 연결하면 이 의미와 맞지 않습니다. 브라우저나 검색 수집기가 주소를 읽는 행위만으로 원치 않는 변경을 일으킬 수 있기 때문입니다.

이 정의는 서버 내부에서 아무 변화도 일어나지 않는다는 보장은 아닙니다. 서버는 GET을 처리하면서 접속 로그를 남길 수 있습니다. 안전성은 클라이언트가 요구한 작업의 의미를 기준으로 하며, 구현이 부수적으로 수행하는 모든 동작을 없애는 규칙은 아닙니다. 통신 내용이 암호화되는지나 응답 자료가 민감한지도 안전한 메서드라는 분류와는 별개의 문제입니다.

GET의 멱등성도 요청이 의도한 효과에 관한 성질입니다. 같은 요청을 반복해도 그 효과는 한 번 보낸 것과 같아야 합니다. 그 사이 서버의 자료가 갱신됐다면 나중 응답은 달라질 수 있고, 서버는 요청마다 로그를 남길 수 있습니다. 멱등이라는 말을 언제 조회해도 동일한 내용이 돌아온다는 뜻으로 해석하면 갱신되는 목록이나 상태 조회를 잘못 이해하게 됩니다.

캐시와 요청 본문의 경계

GET 응답은 캐시할 수 있지만 모든 응답이 자동으로 저장되거나 재사용되는 것은 아닙니다. HTTP 명세는 캐시 제어로 달리 지정하지 않은 경우 GET 응답을 후속 GET이나 HEAD 요청에 사용할 수 있다고 설명합니다. 캐시 가능성은 메서드가 허용하는 성질이고, 실제 재사용 여부는 해당 응답에 적용되는 캐시 조건에 달려 있습니다.

GET 요청 본문에는 일반적으로 합의된 의미가 없습니다. MDN의 GET 문서은 데이터를 요청하는 용도로 사용하고 요청 본문을 넣지 않도록 설명하며, 일부 서버가 본문을 포함한 요청을 거절할 수 있다고 안내합니다. 특정 서버에서 처리됐다는 사실만으로 다른 서버나 중간 장치에서도 같은 방식으로 동작한다고 볼 수는 없습니다.

HTTP 명세도 원 서버에 직접 요청하며 그 서버가 미리 지원과 목적을 알린 경우를 제외하면 클라이언트가 GET 본문을 생성하지 않도록 권고합니다. 서버와 클라이언트 사이의 개별 합의가 있더라도 중간 장치가 그 합의를 알지 못할 수 있습니다. 요청 본문에 별도 처리 지시를 담아 GET의 조회 의미를 바꾸기보다, 필요한 동작의 의미와 서비스가 정의한 요청 방식을 맞추는 것이 상호운용성의 기준입니다.