HTTP 메서드

HTTP 메서드는 클라이언트가 서버에 요청을 보낼 때 수행하고자 하는 기본적인 동작 또는 목적을 나타내는 동사이다. 이는 HTTP 요청의 시작 줄에 위치하며, 서버가 클라이언트의 의도를 이해하고 그에 맞는 적절한 작업을 수행할 수 있도록 지시하는 역할을 한다. 예를 들어, 어떤 리소스를 가져오고 싶은지, 새로 생성하고 싶은지, 수정하거나 삭제하고 싶은지를 명시한다.

HTTP 메서드는 RFC 표준에 의해 정의되며, 각 메서드는 고유한 의미론을 가진다. 가장 널리 사용되는 메서드로는 GET, POST, PUT, PATCH, DELETE 등이 있다. 이러한 메서드들은 RESTful API 설계의 근간이 되어, URI로 식별되는 리소스에 대해 수행할 수 있는 기본적인 CRUD 연산을 매핑하는 데 사용된다. 메서드의 선택은 요청의 성격과 서버의 상태에 어떤 영향을 미칠지 결정한다.

HTTP 메서드는 그 속성에 따라 안전한 메서드와 멱등한 메서드로 분류될 수 있다. 안전한 메서드는 서버의 상태를 변경하지 않는 읽기 전용 작업을 의미하며, GET과 HEAD, OPTIONS 등이 이에 해당한다. 멱등성은 같은 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 서버 상태에 동일한 효과를 가지는 속성을 말한다. GET, PUT, DELETE는 일반적으로 멱등한 메서드로 간주되지만, POST는 멱등하지 않다. 이러한 정의와 분류는 웹 아키텍처의 예측 가능성과 신뢰성을 보장하는 데 기여한다.

안전한 메서드는 서버의 상태를 변경하지 않는 HTTP 메서드를 의미한다. 이 메서드들은 리소스를 조회하거나 정보를 가져오는 데 사용되며, 서버에 저장된 데이터를 수정, 생성, 삭제하지 않는다. 대표적인 안전한 메서드로는 GET과 HEAD, OPTIONS, TRACE가 있다. 안전한 메서드의 요청은 서버에 부작용을 일으키지 않아야 하므로, 로깅이나 통계 수집과 같은 부수적인 효과를 제외하고는 서버의 상태를 변경해서는 안 된다. 이 속성은 웹 크롤러와 같은 자동화된 에이전트가 리소스를 안전하게 탐색할 수 있게 해준다.

멱등성은 동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 서버 상태에 동일한 효과를 가지며, 동일한 응답을 반환하는 속성을 말한다. 즉, 멱등한 메서드의 요청은 한 번 실행하든 여러 번 실행하든 최종 결과가 같아야 한다. GET, HEAD, PUT, DELETE 메서드는 멱등성을 가진다. 예를 들어, 동일한 PUT 요청을 여러 번 보내면 리소스는 최종 요청의 상태로 유지되며, DELETE 요청을 여러 번 보내더라도 리소스는 삭제된 상태로 남아 있다.

안전한 메서드는 모두 멱등성을 가지지만, 그 역은 성립하지 않는다. PUT과 DELETE는 멱등하지만 서버 상태를 변경하기 때문에 안전하지 않다. 반면, POST 메서드는 일반적으로 멱등성을 가지지 않으며 안전하지도 않다. 동일한 POST 요청을 반복하면 새로운 리소스가 계속 생성되는 등의 부작용이 발생할 수 있다.

이러한 속성은 HTTP 클라이언트와 서버의 동작을 예측 가능하게 만들고, 네트워크 장애 발생 시 요청을 안전하게 재시도할 수 있는 근거를 제공한다. 또한 RESTful API 설계 시 리소스에 대한 연산의 특성을 명확히 정의하는 데 중요한 기준이 된다.

GET 메서드는 서버로부터 지정된 URI의 정보를 요청하는 데 사용된다. 이는 HTTP에서 가장 일반적이고 기본적인 메서드이다. 주로 데이터를 읽거나 검색하는 용도로 활용되며, 서버의 상태를 변경하지 않아야 한다는 것이 핵심 원칙이다.

요청은 쿼리 문자열(Query String)을 통해 서버에 추가적인 매개변수를 전달할 수 있다. 이 매개변수는 URL의 물음표(?) 뒤에 이름=값 쌍으로 구성되어 첨부된다. 예를 들어, /search?q=apple&category=fruit와 같은 형태이다. 서버는 이 매개변수를 해석하여 적절한 리소스를 조회하고 결과를 반환한다.

GET 요청의 응답은 일반적으로 캐시 가능하다[2]. 또한, 요청은 브라우저 히스토리에 남고, 북마크될 수 있으며, 길이 제한이 있는 URL을 통해 데이터가 전송되므로 매우 긴 데이터를 전송하는 데는 적합하지 않다. 보안 측면에서, GET 요청으로 전송된 매개변수는 URL에 노출되므로 비밀번호나 개인정보와 같은 민감한 데이터를 전송하는 데 사용해서는 안 된다.

주로 웹 페이지를 불러오거나, 검색 결과를 요청하거나, API를 통해 데이터를 조회하는 등 정보를 검색하는 모든 작업에 GET 메서드가 적용된다.

POST 메서드는 클라이언트가 서버에게 새로운 리소스를 생성하도록 요청하거나, 기존 프로세스에 데이터를 제출할 때 사용된다. 이 메서드는 요청 본문(페이로드)에 서버가 처리할 데이터를 담아 전송하는 것이 특징이다. GET 메서드와 달리, POST 요청은 일반적으로 서버의 상태를 변경하는 부수 효과를 일으킨다.

POST의 가장 일반적인 용도는 새로운 리소스를 생성하는 것이다. 예를 들어, 게시판에 새 글을 작성하거나, 쇼핑몰에서 주문을 생성할 때 POST 요청이 사용된다. 서버는 요청을 성공적으로 처리한 경우, 주로 201 Created 상태 코드와 함께 새로 생성된 리소스의 위치를 Location 헤더에 담아 응답한다. 또한, 기존 리소스에 데이터를 제출하여 특정 작업을 수행하도록 하는 데에도 널리 활용된다. 이는 파일 업로드나 폼 데이터 전송과 같은 경우에 해당한다.

POST 메서드는 멱등성을 보장하지 않는다. 동일한 POST 요청을 여러 번 반복하면, 매번 새로운 리소스가 생성되거나 동일한 작업이 반복 수행될 수 있다. 예를 들어, '주문 생성' 요청을 두 번 보내면 두 개의 별도 주문이 생성될 가능성이 높다. 또한, POST 요청에 대한 응답은 기본적으로 캐시되지 않는다.

POST는 RESTful API 설계에서 생성(Create) 작업을 담당하는 핵심 메서드로, URI는 생성될 리소스의 컬렉션을 나타내는 경로를 사용하는 것이 일반적이다. 예를 들어, /articles에 POST 요청을 보내 새 글을 생성한다.

PUT 메서드는 요청 페이로드가 식별된 URI의 기존 리소스를 완전히 대체하도록 요청합니다. 클라이언트가 제공한 리소스 표현으로 대상 리소스를 완전히 교체하는 것이 기본 동작입니다. 만약 요청 URI에 해당하는 리소스가 존재하지 않으면, 서버는 해당 URI로 새로운 리소스를 생성할 수 있습니다. 이는 POST가 부모 리소스 하위에 새로운 리소스를 생성하는 것과 구별되는 점입니다.

PUT 요청은 멱등성을 가집니다. 동일한 PUT 요청을 여러 번 반복해도 결과는 한 번 실행한 것과 동일하게 유지됩니다[4]. 이는 리소스의 상태를 클라이언트가 완전히 알고 제어할 수 있을 때 유용합니다. 그러나 PUT은 일반적으로 안전한 메서드로 분류되지 않습니다. 서버의 리소스 상태를 변경하기 때문입니다.

PUT과 PATCH의 주요 차이는 리소스를 '완전히 교체'하는지 '부분적으로 수정'하는지에 있습니다. PUT은 리소스의 모든 필드를 업데이트해야 하며, 요청에 포함되지 않은 기존 필드는 null이나 기본값으로 덮어쓰여집니다. 반면 PATCH는 명시된 필드만 수정합니다. 다음은 사용자 정보를 업데이트하는 PUT과 PATCH 요청의 예시적 차이를 보여줍니다.

이러한 특성 때문에, RESTful API 설계에서는 클라이언트가 리소스의 전체 상태를 알고 있을 때(예: 편집 폼 저장) PUT을 사용하고, 일부 필드만 업데이트할 때는 PATCH를 사용하는 것이 일반적입니다.

PATCH 메서드는 서버에 저장된 리소스의 일부를 수정하기 위해 사용된다. PUT 메서드가 리소스를 전체적으로 교체하는 것과 달리, PATCH는 변경하고자 하는 특정 필드나 데이터만을 지정하여 부분적인 업데이트를 수행한다. 이 메서드는 리소스의 전체 상태를 클라이언트가 알 필요 없이 효율적으로 변경할 수 있게 해준다.

PATCH 요청의 본문에는 수행할 변경 사항을 설명하는 패치 문서 형식이 포함된다. 가장 일반적으로 사용되는 형식은 JSON Patch (application/json-patch+json)와 JSON Merge Patch (application/merge-patch+json)이다. JSON Patch는 작업(op), 경로(path), 값(value)으로 구성된 명령어 배열을 사용하여 정교한 변경을 지원한다. 반면 JSON Merge Patch는 변경할 필드와 새로운 값을 가진 JSON 객체를 전송하여 더 간단한 업데이트에 적합하다.

PATCH 메서드는 멱등성이 보장되지 않을 수 있다는 점에 유의해야 한다. 같은 PATCH 요청을 여러 번 보내는 것이 항상 같은 최종 상태를 보장하지는 않는다. 예를 들어, "값에 1을 더하라"는 연산을 수행하는 PATCH 요청은 요청을 반복할 때마다 결과 값이 달라진다. 그러나 "특정 필드를 특정 값으로 설정하라"는 식의 연산은 멱등성을 가질 수 있다. 서버는 PATCH 요청을 처리할 때 충돌이나 오류가 발생하면 적절한 상태 코드(예: 409 Conflict, 422 Unprocessable Entity)로 응답해야 한다.

DELETE 메서드는 서버에 저장된 특정 리소스를 삭제하도록 요청한다. 이 요청이 성공하면 서버는 해당 리소스를 제거하고, 일반적으로 성공 상태 코드 204 No Content(본문 없음) 또는 200 OK(삭제된 리소스 정보를 본문에 포함)로 응답한다. 클라이언트는 요청 URI를 통해 삭제할 리소스를 명시적으로 지정해야 한다.

멱등성을 가지는 메서드 중 하나이다. 즉, 동일한 DELETE 요청을 여러 번 보내도 첫 번째 요청으로 리소스가 삭제된 후에는 추가적인 상태 변화가 발생하지 않는다. 이후의 요청들은 일반적으로 리소스를 찾을 수 없다는 의미의 404 Not Found나 410 Gone 상태 코드를 반환할 수 있다. 그러나 안전한 메서드는 아니다. 서버의 상태를 변경하는 부수 효과를 일으키기 때문이다.

다음은 DELETE 메서드의 주요 응답 코드와 의미를 정리한 표이다.

RESTful API 설계에서 DELETE는 리소스 컬렉션(/articles/123)이나 특정 리소스에 대한 하위 컬렉션(/articles/123/comments/456)을 삭제하는 데 사용된다. 서버는 요청을 받아들일지 여부를 결정할 수 있으며, 삭제 작업이 실제 데이터베이스에서 물리적 삭제인지 논리적 삭제(삭제 플래그 설정)인지는 구현에 따라 다르다.

HEAD 메서드는 GET 요청과 동일한 응답을 생성하지만, 응답 본문을 포함하지 않는다. 주로 리소스의 존재 여부나 HTTP 헤더 정보(예: 콘텐츠 타입, 콘텐츠 길이, 최종 수정 시간 등)를 확인하는 데 사용된다. 이를 통해 클라이언트는 실제 데이터를 다운로드하지 않고도 리소스의 메타데이터를 얻을 수 있어 대역폭을 절약할 수 있다.

OPTIONS 메서드는 특정 리소스에 대해 서버가 지원하는 통신 옵션을 묻는 데 사용된다. 주로 CORS(Cross-Origin Resource Sharing) 사전 요청(*Preflight Request*)에서 사용되며, 서버는 Allow 헤더를 통해 지원하는 HTTP 메서드 목록(예: GET, POST, PUT)을 응답한다. 이는 클라이언트가 서버의 능력을 사전에 파악할 수 있게 한다.

TRACE 메서드는 클라이언트의 요청이 서버에 도달하는 과정에서 어떠한 변경이 있었는지 진단하는 데 사용된다. 서버는 수신한 요청 메시지를 그대로 응답 본문에 포함시켜 반환한다. 이는 주로 중간에 위치한 프록시 서버나 게이트웨이가 메시지를 어떻게 변형시키는지 확인하는 디버깅 목적으로 활용된다. 그러나 크로스 사이트 트레이싱(Cross-Site Tracing)과 같은 보안 공격에 악용될 수 있어, 현대 웹 서버에서는 보안상의 이유로 비활성화되는 경우가 많다.

CONNECT 메서드는 요청한 리소스와 양방향 통신을 시작하는 데 사용되며, 주로 SSL(Secure Sockets Layer) 터널링을 통해 HTTPS 연결을 설정할 때 사용된다. 클라이언트가 프록시 서버를 통해 목적지 서버와 TLS(Transport Layer Security) 세션을 수립해야 할 때, CONNECT 요청을 통해 프록시에 터널 연결을 요청한다. 이 메서드는 일반적인 HTTP 요청/응답 흐름과는 다른, 저수준의 네트워크 연결을 설정하는 역할을 담당한다.

HTTP 메서드의 캐시 가능성은 해당 메서드로 이루어진 응답이 클라이언트나 중간 프록시 서버에 의해 캐시되어 재사용될 수 있는지를 나타내는 속성이다. 이 속성은 네트워크 효율성과 성능 최적화에 직접적인 영향을 미친다.

일반적으로 GET과 HEAD 메서드는 캐시 가능한 것으로 정의된다. 이 메서드들은 서버의 상태를 변경하지 않는 안전한 메서드이므로, 동일한 요청에 대한 응답을 캐시해도 부작용이 발생하지 않는다. 서버는 응답 시 Cache-Control이나 Expires와 같은 HTTP 헤더를 사용하여 해당 리소스의 캐시 정책(예: 유효 기간, 재검증 필요 여부)을 명시적으로 제어할 수 있다. 반면, POST, PUT, DELETE, PATCH와 같은 서버 상태를 변경하는 메서드는 기본적으로 캐시되지 않는다. 그러나 특별한 Cache-Control 지시어를 사용하거나, 응답에 명시적인 유효성 검사 헤더를 포함시켜 제한적으로 캐시를 허용할 수도 있다[9].

다음은 주요 HTTP 메서드의 캐시 가능성과 관련 속성을 비교한 표이다.

캐시 가능성은 웹 성능 최적화의 핵심 요소이다. 적절한 캐시 정책을 적용하면 불필요한 네트워크 왕복을 줄이고 서버 부하를 감소시키며, 최종 사용자에게 더 빠른 응답 속도를 제공할 수 있다. 따라서 API 설계 시 리소스의 특성과 메서드의 의미론적 속성을 고려하여 캐시 가능성을 염두에 두는 것이 중요하다.

네 가지 주요 HTTP 메서드는 각각 고유한 의미와 사용 사례를 가지며, RESTful API 설계 시 이들의 차이를 이해하는 것이 중요하다.

GET은 서버의 데이터를 변경하지 않고 오직 조회만을 목적으로 한다. 따라서 캐시가 가능하며, 브라우저 히스토리에 남거나 북마크될 수 있다. 반면 POST는 주로 새로운 리소스를 생성하거나, 데이터를 처리하는 데 사용된다. 같은 POST 요청을 반복하면 부수 효과(예: 중복 주문 생성)가 발생할 수 있어 멱등하지 않다.

PUT은 요청 페이로드로 제공된 데이터로 지정된 리소스를 완전히 대체한다. 리소스가 존재하면 갱신하고, 없으면 생성하는 경우가 많다. 같은 PUT 요청을 여러 번 보내도 최종 결과는 동일하므로 멱등하다. PATCH는 리소스의 일부만을 수정할 때 사용한다. 수정할 필드에 대한 지시사항(예: JSON Patch)을 본문에 담아 보내며, 구현 방식에 따라 멱등하지 않을 수 있다.

REST 아키텍처 스타일의 핵심은 모든 것을 리소스로 표현하고, 이 리소스에 대한 조작을 HTTP 메서드를 통해 수행하는 것이다. 리소스 중심 설계의 첫 번째 원칙은 URI가 정보 자체를 지시해야 한다는 점이다. URI는 리소스의 이름이나 식별자 역할을 하며, 리소스에 대한 행위(생성, 조회, 수정, 삭제)는 HTTP 메서드가 담당한다. 예를 들어, /books/123이라는 URI는 'ID가 123인 책'이라는 리소스를 가리키며, 이에 대한 행위는 GET, PUT, DELETE 등의 메서드로 구분된다.

두 번째 원칙은 리소스 간의 관계를 계층 구조로 표현하는 것이다. 이는 URI 경로를 통해 자연스럽게 구현된다. 예를 들어, 특정 책의 리뷰 목록은 /books/123/reviews로, 특정 리뷰는 /books/123/reviews/456으로 표현할 수 있다. 이러한 구조는 API의 직관성과 일관성을 높인다.

표준화된 HTTP 메서드를 사용하는 것이 세 번째 원칙이다. 각 메서드는 명확한 의미를 가지며, 이를 일관되게 적용해야 한다. 주요 메서드의 역할은 다음과 같다.

마지막으로, HATEOAS 원칙을 통해 API의 상태 전이를 명시하는 것이 이상적인 리소스 중심 설계이다. 이는 응답에 현재 리소스에서 수행 가능한 다음 작업에 대한 링크(URI)를 포함시켜, 클라이언트가 하이퍼미디어를 통해 동적으로 애플리케이션 상태를 탐색할 수 있게 한다. 예를 들어, 책 목록 조회 응답에 각 책의 상세 정보를 가져오는 링크나 새 책을 생성하는 링크를 포함시킬 수 있다.

RESTful API 설계에서 적절한 HTTP 메서드를 선택하는 것은 리소스의 상태와 클라이언트의 의도를 명확하게 표현하는 데 중요하다. 일반적인 가이드라인은 수행하려는 작업의 본질에 따라 결정된다. 새로운 리소스를 생성할 때는 POST를 사용하고, 기존 리소스를 조회할 때는 GET을 사용한다. 리소스를 완전히 교체하거나 지정된 위치에 생성할 때는 PUT을, 리소스의 일부 필드만 수정할 때는 PATCH를 선택한다. 리소스를 삭제하는 작업에는 DELETE 메서드가 적합하다.

보다 구체적인 시나리오에 따른 선택 기준은 다음과 같다. 클라이언트가 서버에 데이터를 제출하되 결과 URI를 모를 때(예: 게시글 작성)는 POST를 사용한다. 클라이언트가 생성될 리소스의 URI를 알고 있을 때(예: 특정 사용자 프로필 생성/교체)는 PUT을 사용할 수 있다. 리소스의 상태를 변경하지 않는 단순 조회 작업은 항상 안전한 메서드인 GET을 사용해야 한다. 멱등성이 보장되어야 하는 작업, 즉 동일한 요청을 여러 번 보내도 한 번 보낸 것과 같은 효과를 내는 작업에는 GET, PUT, DELETE를 사용하는 것이 바람직하다.

최종적으로 메서드 선택은 API의 예측 가능성과 일관성을 높이는 방향으로 이루어져야 한다. 같은 종류의 작업(예: 사용자 정보 수정)에 대해 상황에 따라 PATCH와 PUT이 혼용되지 않도록 통일된 규칙을 정하는 것이 좋다. 또한, 리소스의 상태를 변경하는 작업을 GET 메서드에 쿼리 파라미터로 수행하는 것은 REST 원칙과 HTTP 표준에 어긋나며, 보안상의 문제와 캐싱 오류를 초래할 수 있으므로 피해야 한다.

크로스 사이트 요청 위조(CSRF)는 사용자가 자신의 의지와 무관하게 공격자가 의도한 HTTP 요청을 보내도록 만드는 공격 기법이다. 이 공격은 주로 세션 쿠키나 기본 인증 정보를 자동으로 포함하는 브라우저의 동작을 악용한다. HTTP 메서드의 특성은 CSRF 공격의 실행 가능성과 방어 전략에 직접적인 영향을 미친다.

안전하지 않은 메서드(Non-safe Methods), 즉 서버의 상태를 변경할 수 있는 POST, PUT, PATCH, DELETE 메서드는 CSRF 공격의 주요 대상이 된다. 반면, 상태를 변경하지 않는 GET 메서드는 원칙적으로 CSRF 공격에 사용되어서는 안 된다. GET 요청은 리소스 조회용으로 설계되었으며, URL에 파라미터가 노출되고 웹 브라우저에 의해 프리페치되거나 캐시될 수 있어, 부수적인 상태 변경을 유발하면 보안 및 설계상의 문제를 일으킬 수 있다[15].

CSRF 방어를 위해서는 안전하지 않은 메서드를 사용하는 모든 상태 변경 요청에 대해 추가적인 검증 수단을 적용해야 한다. 대표적인 방어 방법으로는 CSRF 토큰 사용, SameSite 쿠키 속성 설정, 중요한 작업 전에 재인증 요구 등이 있다. 또한, RESTful API 설계 시 멱등성을 고려하여 PUT 메서드를 적절히 활용하면, 일부 공격 시나리오에서의 영향도를 줄이는 데 도움이 될 수 있다. 결국, 각 HTTP 메서드의 정의된 의미와 속성을 준수하는 것이 올바른 API 설계뿐만 아니라 보안 취약점 예방의 기본이 된다.

민감한 작업, 예를 들어 사용자 인증, 결제 처리, 개인정보 변경 등은 적절한 HTTP 메서드 선택이 보안에 직접적인 영향을 미친다. 일반적으로 GET 메서드는 URL에 파라미터가 노출되며 브라우저 히스토리나 서버 로그에 남을 수 있어, 비밀번호나 신용카드 번호 같은 민감한 데이터 전송에는 절대 사용해서는 안 된다. 또한 GET 요청은 예기치 않게 캐시되거나 프리페치될 수 있어 데이터 유출 위험이 더욱 커진다.

이러한 작업에는 주로 POST, PUT, PATCH와 같은 요청 본문(Request Body)에 데이터를 실을 수 있는 메서드가 권장된다. 특히 POST는 멱등성이 보장되지 않아 동일한 요청이 여러 번 처리될 수 있다는 점에서, 결제와 같은 중복 실행을 방지해야 하는 트랜잭션에 추가적인 서버 측 검증 로직이 필요하다. PUT 메서드는 전체 리소스를 교체하는 멱등한 특성을 가지지만, 사용자 권한 변경과 같은 부분 업데이트에는 PATCH가 더 적합할 수 있다.

또한, HTTPS를 통한 암호화된 채널 사용은 모든 민감한 작업의 필수 전제 조건이다. 메서드 선택과 무관하게 평문 HTTP를 통해 전송되는 데이터는 중간자 공격(Man-in-the-Middle Attack)에 노출된다. 서버 측에서는 클라이언트의 신원과 권한을 철저히 검증하는 인가(Authorization) 절차와 함께, 입력 데이터의 유효성 검증 및 크로스 사이트 요청 위조 방지 토큰 사용과 같은 추가 보안 계층을 적용해야 한다.