HTTP Semantics (RFC 9110) 정리(2)

9. method

9.1 개요

요청 method는 요청 구문의 주요한 부분으로
클라이언트의 요청의 목적과 요청이 성공했을 경우 어떠한 결과를 기대하는지를 나타낸다.

일반적으로 사용하는 표준화된 메서드들

• GET : 대상 리소스의 현재 표현을 전송함
• HEAD : GET과 동일하지만 응답 내용을 전송하지 않음
• POST : 요청 내용의 리소스별 처리를 수행함
• PUT : 대상 리소스의 표현을 요청한 내용으로 변경함
• DELETE : 대상 리소스의 표현을 모두 제거함
• CONNECT : 대상 리소스에 식별된 서버에 대해 터널을 설정함
• OPTIONS : 대상 리소스에 대한 통신 옵션을 설명함
• TRACE : 대상 리소스의 경로를 따라 메시지 루프백 테스트를 수행함 루프백 테스트 → 통신 상 어느 지점에서 에러가 발생하였는지 확인하는 테스트
  

모든 서버는 GET과 HEAD method를 지원해야하고 다른 method들은 선택 사항이다.
대상 리소스에서 허용되는 메세지 집합은 allow header field에 나열해야함.
인식할 수 없는 메서드와 구현되지 않은 요청을 받은 경우 오리진 서버는 501 상태 코드로 응답해야함
대상 리소스에 대해 허용되지는 않지만 인식 및 구현된 요청 메시지를 수신할 경우에는 405 상태 코드로 응답해야함

501 → Not Implemented

405 → Method Not Allowed

9.2 safe methods

9.2.1 safe methods

읽기 전용으로 정의된 method을 safe method라고 부른다. safe method는 서버의 상태 변경을 요청하지 않는다.
본 명세서에 정의된 GET, HEAD, OPTIONS, TRACE는 safe method이다.

사용자 에이전트는 사용자가 요청시 safe한 요청인지 unsafe한 요청인지 인식할 수 있게 해야한다.
(삭제시 사용자에게 alert해주기 등등)

9.2.2 idempotent method (멱등의 메서드)

동일한 여러 요청의 결과가 한번의 요청의 결과와 같을경우 idempotent method라고 부른다.
본 명세서에서 정의된 PUT, DELETE, safe method가 멱등한 메서드에 해당한다.

idempotent method는 클라이언트가 서버의 응답을 읽기전에 연결이 끊긴 경우 자동으로 재실행될 수 있다.

클라이언트는 method와 관계없이,

해당 요청이 실제로는 idempotent할것이라는 것을 인식할 수 있는 수단이 있거나
원래 요청이 적용되지 않았음을 인식할 수 있는 방법이 있는게 아니라면
non-idempotent method 요청을 자동으로 재실행 해서는 안된다.

프록시는 non-idempotent 요청을 자동으로 실행하면 절대 안된다.

9.2.3 method와 캐싱

캐시가 응답을 저장하고 사용하려면 메서드가 캐싱을 허용함을 명시하고 후속 요청을 충족할 수 있는 조건을 상세히 설명해야한다

일반적으로 많은 서버가 GET과 HEAD만 캐싱을 지원한다.

9.3 method 정의

9.3.1 GET

대상 resource의 현재 표현을 전송할것을 요청한다. 응답이 성공했다면 resource의 “동일성”을 보장한다.

GET은 정보 검색의 주요 매커니즘이고 거의 모든 성능 최적화의 초점이다. 각 리소스에 대한 URI를 생성하는 프로그램은 리소스를 재사용해 성능을 최적화할 수 있고 웹을 더욱 확장할 수 있도록 한다.

client는 요청시 Range 헤더 필드를 전송해 선택한 표현의 일부만 전송하는 “범위 요청”으로 변경할 수 있다.

• range header
  range 요청 헤더를 받으면 resource를 여러번 나눠서 보낼 수 있다.

GET은 대상을 검색하기 위해 query string 형태로 검색 정보를 URI에 포함해서 전송할 수 있는데, 이떄 민감한 데이터를 포함하지 않도록 주의해야하고 POST를 사용해 body로 전송하는 방식을 대신 사용할 수 있다.

GET 요청에 대한 응답은 캐시 가능하다.

9.3.2 HEAD

HEAD method는 서버가 응답에 내용을 전송하면 안된다. HEAD는 hypertext link를 테스트하거나 최근 수정사항을 찾기 위해 선택된 표현에 대한 메타데이터를 얻기 위해 사용된다.

HEAD 요청에 대한 응답은 캐싱 가능하다.

9.3.3 POST

POST 메서드는 target resource가 요청에 포함된 표현을 resource 고유의 특정 의미론에 따라 처리할 것을 요청한다.
origin 서버는 POST 요청을 처리 결과에 따라 적절한 상태 코드를 선택해 응답한다.

POST 요청을 성공적으로 처리해 origin 서버에 하나 이상의 리소스가 생성된 경우 생성된 리소스에 대한 식별자를 제공하는 Location header 필드를 포함하는 201(created) 상태로 응답을 전송해야한다.

POST 요청은 대상 URI와 동일한 값을 가진 Content-Location 헤더 필드가 포함된 경우에만 캐시 가능하다.

• Content-Location header
  요청한 리소스에 여러 표현이 있는 경우에 사용함.

9.3.4 PUT

target resource를 요청 메세지에 내용에 포함된 표현으로 생성되거나 교체한다. PUT의 성공적인 응답은 요청 성공 후 target resource를 GET으로 요청했을때 200으로 응답받을 경우와 같은 내용으로 응답해야한다. 하지만 다른 사용자 에이전트에 의해 병렬적으로 처리될 수 있으므로 target resource의 최신성은 보장할 수 없고, 성공 응답은 사용자 에이전트의 의도가 달성하였음을 나타낸다.

PUT을 통해 현재 표현을 생성한 경우에는 201(created)로 응답해야하고, 수정이 성공한 경우에는 200 또는 204(No Content)로 응답해야한다.

9.3.5 DELETE

target resource가 현재 기능 간의 연결을 제거하도록 요청한다.
연관 정보가 삭제되기 보다는 origin 서버의 URI 매핑에 대한 삭제 작업을 표현한다.

DELETE 메서드가 성공적으로 적용될 경우 서버가 보내야할 내용은 다음과 같다.

• 202 (Accepted) → 작업이 성공할 가능성이 높지만 아직 제정되지 않음
• 204 (No Content) → 작업이 제정되어 추가 정보가 제공되지 않는 경우
• 200 → 작업에 제정되어 응답 메세지에 상태를 설명하는 표현이 포함된 경우

9.3.6 CONNECT

수신자가 요청 대상에 의해 식별된 대상 오리진 서버에 대한 터널을 설정한다. 설정 성공할 경우 터널이 닫힐 떄까지 양방향으로 데이터의 블라인드 포워딩으로 동작을 제한하도록 요청한다.

2xx 응답은 송신자가 터널 모드로 전환됨을 나타낸다. 터널 매개체가 어느 한쪽이 연결을 닫았음을 감지하면 터널이 닫힌다.

9.3.7 OPTIONS

target resource에 사용 가능한 통신 옵션에 대한 정보를 요청한다.

OPTION 요청에 대한 응답은 서버가 target resource에 적용할 수 있는 옵션 기능을 나타낼 수 있는 헤더를 전송해야한다.

OPTIONS 메서드의 응답은 캐시할 수 없다.

9.3.8 TRACE

요청의 최종 수신자는 일부 필드를 제외하고 수신된 메시지를 200(Ok) 응답의 내용으로 클라이언트에 다시 반영해야한다. 클라이언트는 응답에 의해 노출될 수 있는 중요한 데이터(쿠키, 사용자 자격 증명)를 요청 필드에 포함하면 안된다.

클라이언트는 TRACE 요청에 컨텐츠를 전송하면 안된다.

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