4. Request Methods

4.1 Overview

요청 메서드 토큰은 요청 의미론의 주 소스로서, 클라이언트가 이러한 요청을 한 목적과 성공적인 결과로 클라이언트가 기대하는 바를 나타낸다.

HTTP는 원래 분산 객체 시스템에 대한 인터페이스로 사용할 수 있도록 설계되었다.메서드 토큰은 대소문자를 구분하는 메서드 이름을 가진 객체 기반 시스템의 게이트웨이로 사용될 수 있기 때문에 대소문자를 구분한다.

분산된 객체와 달리, 획일화된 인터페이스는 네트워크 기반 시스템 [REST]에서 더 나은 가시성과 재사용을 제공하므로, HTTP의 표준화된 요청 메서드는 리소스에 국한된 것이 아니다. 일단 정의되면, 표준화된 메서드는 각 리소스의 그 의미론들이 구현되거나 허용되는지 스스로 결정함에도 불구하고, 어떤 리소스에 적용될 때는 동일한 의미론들을 가져야 한다.

• 모든 범용 서버는 GET 및 HEAD 메서드를 지원해야 한다. 다른 모든 메서드는 선택사항이다. (OPTIONAL)

4.2 Common Method Properties

4.2.1 Safe Methods

요청 메서드는 정의된 의미론이 본질적으로 읽기 전용인 경우, 즉 클라이언트가 대상 리소스에 안전한 메서드를 적용한 결과 원서버의 상태 변경을 요청하지 않고 예상하지 않는 경우 “safe”로 간주된다.

중요한 것은 클라이언트가 추가 행동을 요구하지 않았고 이에 대한 책임을 물을 수 없 다는 것이다. 예를 들어, 대부분의 서버는 메서드에 관계없이 모든 응답이 완료될 때 로그 파일에 액세스하기 위해 요청 정보를 추가하며, 로그 저장소가 가득 차서 서버가 다운될 수 있더라도 안전하다고 간주된다.

이 명세에 의해 정의된 요청 메서드 중 GET, HEAD, OPTION 및 TRACE 메서드는 안전하다고 정의된다.

안전한 메서드와 안전하지 않은 메서드를 구분하는 목적은 자동 검색 프로세스(spider)와 캐시 성능 최적화(pre-fetching)가 위해를 일으킬 염려 없이 작동할 수 있도록 하기 위함이다. 또한 잠재적으로 신뢰할 수 없는 콘텐츠를 처리할 때 안전하지 않은 메서드의 자동 사용에 대해 사용자 에이전트가 적절한 제약조건을 적용할 수 있도록 한다.

• 리소스의 목적이 안전하지 않은 작업을 수행하는 것이라면, 리소스 소유자는 안전한 요청 메서드를 사용하여 액세스할 때 해당 작업을 비활성화하거나 허용하 지 않아야 한다.(MUST)

4.2.2 Idempotent Methods

멱등성 - 용어 사전 | MDN

요청 메서드는 해당 메서드와의 복수의 동일한 요청의 서버에 대한 의도된 효과가 단일 요청의 효과와 동일한 경우, “멱등성(idempotent)”으로 간주된다. 이 명세에 의해 정의된 요청 메서드 중 PUT, DELETE 및 안전 요청 메서드는 멱등하다.

4.2.3 Cacheable Methods

요청 메서드는 “cacheable”으로 정의하여 향후 재사용에 대한 응답을 저장할 수 있음을 나타낼 수 있다. 일반적으로 현재 또는 권한 있는 응답 에 의존하지 않는 안전한 메서드는 캐시 가능으로 정의된다. 이 규격은 GET, HEAD 및 POST를 캐시 가능으로 정의하지만, 압도적으로 과반수의 캐시 구현은 GET와 HEAD만 지원한다.

4.3 Method Definitions

4.3.1 GET

GET 메서드는 대상 리소스에 대해 현재 선택된 표현의 전송을 요청한다. GET는 정보 검색의 주요 메커니즘이자 거의 모든 성능 최적화의 초점이다.

URI 매핑 메커니즘이 파일 시스템에 연결되어 있는 경우에도 원서버는 요청으로 파일을 입력으로 실행하고 파일을 직접 전송하지 않고 출력물 을 표현으로 전송하도록 구성할 수 있다.

클라이언트는 요청에서 Range 헤더 필드([RFC7233]) 를 전송하여 선택된 표현의 일부만 전송을 요청하는 GET의 의미를 “range request”로 변경할 수 있다.

4.3.2 HEAD

• HEAD 메서드는 GET과 동일하지만, 서버가 응답에서 메시지 본문을 전송하면 안 된다.(MUST NOT)

• 서버는 HEAD 요청에 응답하여 GET 요청과 동일한 헤더 필드를 전송해야 한다.(SHOULD)

이 메서드는 표현 데이터를 전송하지 않고 선택된 표현에 대한 메타데 이터를 얻는 데 사용할 수 있으며 유효성, 접근성 및 최근 수정을 위한 하이퍼텍스트 링크 테스트에 종종 사용된다.

HEAD 요청에 대한 응답은 캐시가 가능하며, 캐시는 Cache-Control 헤더 필드에 달리 표시되지 않는 한 후속 HEAD 요청을 만족시키기 위해 캐시를 사용할 수 있다.(MAY) ([RFC7234] 의 Section 5.2). HEAD 응답은 GET에 대한 이전에 캐시된 응답에도 영향을 미칠 수 있다.

4.3.3 POST

POST 메서드는 대상 리소스 요청에 동봉된 표현을 리소스 자체의 특정 의미에 따라 처리하도록 요청한다. 예를 들어, POST는 다음 기능(다른 기능 중)에 사용된다.

• HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공;

• 게시판, 뉴스 그룹, 메일 목록, 블로그 또는 유사한 기사 그룹에 메시지 게시;

• 원서버에서 아직 식별되지 않은 새 리소스 생성; 및

• 리소스의 기존 표현에 데이터 추가

원서버는 POST 요청 처리 결과에 따라 적절한 상태 코드를 선택하여 응답 의미론을 표시하며, 이 규격에 의해 정의된 상태 코드는 거의 모두 POST(206(Partial Content), 304(Not Modified), 416(Range Not Satisfiable)에 대한 응답으로 수신될 수 있다.

• POST 요청을 성공적으로 처리한 결과로써 하나 이상의 리소스가 원서버에 생성된 경우, 원서버는 새로운 리소스를 참조하는 동안 생성된 기본 리소스의 식별자를 제공하는 Location 헤더 필드(Section 7.1.2)를 포함하는 201(Created)응답과 요청의 상태를 설명하는 표현을 전송해야 한다.(SHOULD)

POST 요청에 대한 응답은 명시적인 신선도 정보를 포함하는 경우에만 캐시할 수 있다 ([RFC7234]의 Section 4.2.1 참조). 그러나 POST 캐싱은 널리 구현되지 않는다.

4.3.4 PUT

PUT 메서드는 대상 리소스의 상태를 생성하거나 요청 메시지 페이로드에 동봉된 표현에 의해 정의된 상태로 대체할 것을 요청한다.

• 대상 리소스가 현재 표현을 가지고 있지 않고 PUT이 성공적으로 생성한다면, 원서버는 201 (Created) 응답을 전송하여 사용자 에이전트에게 알려야 한다.(MUST)

• 대상 리소스가 현재 표현을 가지고 있고 그 표현이 동봉된 표현 상태에 따라서 성공적으로 수정되는 경우, 원서버는 요청의 성공적인 완료를 나타내기 위해 200 (OK) 또는 204 (No Content) 응답을 보내야 한다.(MUST)

• 원서버는 PUT 요청으로 인식되지 않는 수신된 헤더 필드를 무시해야 한다.(SHOULD) (i.e., 그것들을 리소스 상태의 일부로 저장하지 마라).

일반적으로 리소스 인터페이스 뒤에 있는 모든 구현 세부사항은 서버에 의해 의도적으로 숨겨진다.

• 원서버는 요청의 표현 데이터가 본문에 적용된 변환 없이 저장되고(i.e., 리소스의 새로운 표 현 데이터가 PUT 요청에서 수신된 표현 데이터와 동일한 경우) 검증자 필드 값이 새로운 표현 을 반영하지 않는 한, PUT에 대한 성공적인 응답으로 ETag 또는 Last-Modified 필드 같은 검 증자 헤더 필드(Section 7.2)를 전송해서는 안된다.(MUST NOT)

이 요구사항은 사용자 에이전트가 PUT의 결과로 메모리에 있는 표현 본문이 최신 상태로 유지되는 시기를 알 수 있도록 허용 하며, 따라서 원서버에서 다시 검색할 필요가 없으며, 응답에 수신된 새 검증자를 우발적인 덮어쓰기를 방지하기 위해 향후 조건부 요청에 사용될 수 있다(Section 5.2).

POST 메서드와 PUT 메서드의 근본적인 차이는 동봉된 표현에 대한 다른 의도에 의해 강조된다. POST 요청의 대상 리소스는 리소스 자체의 의미에 따라 동봉된 표현을 처리하기 위한 것이며, PUT 요청의 동봉된 표현은 대상 리소스의 상태를 대체하는 것으로 정의된다. 따라서 PUT의 의도는 멱등하며, 정확한 효과는 원서버에 의해서만 알려져 있음에도 불구하고 중개에게 보여진다.

post vs put우리집앞마당

PUT 요청에 대한 적절한 해석은 사용자 에이전트가 원하는 대상 리소스를 알고 있다고 가정한다.

• 특정 대상 리소스에 PUT를 허용하는 원서버는, PUT이 전체 표현으로서 잘못 표현된 부분 콘텐츠일 가능성이 있으므로 Content-Range 헤더 필드([RFC7233] Section 4.2)를 포함하는 PUT 요청에 400 (Bad Request) 응답을 보내야 한다.(MUST)

PUT 메서드에 대한 응답은 캐시할 수 없다.

4.3.5 DELETE

DELETE 메서드는 원서버가 대상 리소스와 대상 리소스의 현재의 상관 관계를 제거하도록 요청한다. 사실상, 이 메서드는 UNIX의 rm 명령과 유사하다: 이것은 이전에 연관된 정보가 삭제될 것이라는 기대보다는 원서버의 URI 매핑에 대한 삭제 작업을 표현한다.

DELETE 메서드에 대한 응답은 캐시할 수 없다.

4.3.6 CONNECT

CONNECT 메서드는 수신자에게 요청 대상으로 식별된 대상 원서버에 터널을 설정하도록 요청하고, 그 후, 터널이 닫힐 때까지 패킷의 블라인드 포워딩으로 동작을 제한한다. 터널은 일반적으로 하나 이상의 프락시를 통해 end-to-end 가상 커넥션을 생성하는 데 사용되며, 이후 TLS(Transport Layer Security, [RFC5246])를 사용하여 보안을 유지할 수 있다.

CONNECT는 프락시에 대한 요청에서만 사용할 수 있다.

CONNECT 요청을 전송하는 클라이언트는 요청 대상의 권한 양식을 전송해야 한다 ([RFC7230]의 Section 5.3). 즉, 요청 대상은 콜론으로 구분된 터널 대상의 호스트 이름과 포트 번호로만 구성된다. 예를 들면

CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80

• 터널 중개자는 어느 한쪽이 커넥션을 닫았음을 감지할 때 터널이 닫힌다: 중개자는 닫힌 쪽에 서 온 미결 데이터를 다른 쪽으로 보내고, 양쪽 커넥션을 모두 닫은 다음, 전달되지 않은 나머지 데이터는 모두 폐기해야 한다.(MUST)

프록시 인증을 사용하여 터널 생성 권한을 설정할 수 있다. 예를 들면

CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80 Proxy-Authorization: basic aGVsbG86d29ybGQ=

• 서버는 2xx (Successful) 응답으로 CONNECT에 Transfer-Encoding 또는 Content-Length 헤더 필드를 전송해서는 안 된다.(MUST NOT)

• 클라이언트는 CONNECT에 대한 성공적인 응답으로 수신된 Content-Length 또는 Transfer-Encoding 헤더 필드를 무시해야 한다.(MUST)

CONNECT 메서드에 대한 응답은 캐시할 수 없다.

4.3.7 OPTIONS

OPTION 메서드는 대상 리소스에 사용할 수 있는 통신 옵션에 대한 정보를 오리진 서버 또는 중개자에게 요청한다. 이 메서드를 사용하면 클라이언트가 리소스 작업을 암시하지 않고 리소스 또는 서버의 기능과 관련된 옵션 또는 요구 사항을 결정할 수 있다.

별표("*")를 요청 대상으로 하는 OPTIONS 요청([RFC7230]의 Section 5.3)은 특정 리소스가 아닌 일반적으로 서버에 적용된다. "*" 요청은 "ping" 또는 "no-op" 유형의 메소드만 유효하며, 클라이언트가 서버의 기능을 테스트할 수 있도록 허용하는 것 외에는 아무 것도 하지 않는다. 예를 들어, HTTP/1.1 적합성(또는 그것들의 결여)에 대한 프록시를 테스트하는 데 사용할 수 있다.

요청 대상이 별표가 아닌 경우 OPTION 요청은 대상 리소스와 통신할 때 사용할 수 있는 옵션에 적용된다.

• 응답에서 페이로드 본문을 전송하지 않으려면 서버는 “0”의 값을 가진 Content-Length 필드를 생성해야 한다.(MUST)

• 요청이 Max-Forwards 필드와 수신되지 않은 경우 프록시는 요청을 전달하는 동안 Max-Forwards 헤더 필드를 생성해서는 안 된다.(MUST NOT)

• 페이로드 본문을 포함하는 OPTIONS 요청을 생성하는 클라이언트는 미디어 타입 표현을 설명하는 유효한 Content-Type 헤더 필드를 전송해야 한다.(MUST)

OPTIONS 메서드에 대한 응답은 캐시할 수 없다.

4.3.8 TRACE

TRACE 메서드는 요청 메시지의 원격 애플리케이션-레벨 루프백을 요청한다.

요청의 최종 수신자는 아래에 설명된 일부 필드를 제외하고 수신된 메시지를 “message/http”의 내용 유형으 로 200 (OK) 응답의 메시지 본문으로 클라이언트에 다시 반영해야 한다.(SHOULD)

• 클라이언트는 TRACE 요청에서 응답에 의해 공개될 수 있는 중요한 데이터를 포함하여 헤더 필드를 생성해서는 안 된다.(MUST NOT)

• 클라이언트는 TRACE 요청으로 메시지 본문을 보내서는 안 된다.(MUST NOT)

TRACE 메서드에 대한 응답은 캐시할 수 없다.