상세하지만 HTTP 1.1 메소드 스펙에서 복사되었습니다. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html .
9.3 GET
GET 메소드는 Request-URI에 의해 식별되는 모든 정보 (엔티티 형태)를 검색하는 것을 의미합니다. Request-URI가 데이터 생성 프로세스를 참조하는 경우, 해당 텍스트가 프로세스의 출력이 아닌 한, 프로세스의 소스 텍스트가 아닌 응답의 엔티티로 리턴되는 생성 된 데이터입니다.
요청 메시지에 If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match 또는 If-Range 헤더 필드가 포함 된 경우 GET 메소드의 의미는 "조건부 GET"으로 변경됩니다. 조건부 GET 메소드는 조건부 헤더 필드에 설명 된 상황에서만 엔티티를 전송하도록 요청합니다. 조건부 GET 방법은 클라이언트가 이미 보유한 데이터를 여러 번 요청하거나 전송하지 않고도 캐시 된 엔터티를 새로 고치도록하여 불필요한 네트워크 사용을 줄이려고합니다.
요청 메시지에 Range 헤더 필드가 포함 된 경우 GET 메소드의 의미가 "부분 GET"으로 변경됩니다. 14.35 절에서 설명한 것처럼 부분 GET은 엔티티의 일부만 전송하도록 요청합니다. 부분 GET 방법은 클라이언트가 이미 보유한 데이터를 전송하지 않고 부분 검색된 엔티티를 완료 할 수 있도록함으로써 불필요한 네트워크 사용을 줄입니다.
GET 요청에 대한 응답은 섹션 13에 설명 된 HTTP 캐싱 요구 사항을 충족하는 경우에만 캐시 가능합니다.
양식에 사용될 때 보안 고려 사항은 15.1.3 절을 참조하십시오.
9.5 POST
POST 메소드는 오리진 서버가 요청에 포함 된 엔티티를 요청 라인의 Request-URI에 의해 식별 된 자원의 새로운 하위 항목으로 승인하도록 요청하는 데 사용됩니다. POST는 균일 한 방법으로 다음 기능을 처리 할 수 있도록 설계되었습니다.
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
- Providing a block of data, such as the result of submitting a
form, to a data-handling process;
- Extending a database through an append operation.
POST 방법으로 수행되는 실제 기능은 서버에 의해 결정되며 일반적으로 Request-URI에 따라 다릅니다. 게시 된 엔티티는 파일이 포함 된 디렉토리에 종속되거나 뉴스 기사가 게시 된 뉴스 그룹에 종속되거나 레코드가 데이터베이스에 종속 된 것과 동일한 방식으로 해당 URI에 종속됩니다.
POST 메소드에 의해 수행 된 조치로 인해 URI로 식별 할 수있는 자원이 생성되지 않을 수 있습니다. 이 경우 응답에 결과를 설명하는 엔터티가 포함되어 있는지 여부에 따라 200 (OK) 또는 204 (No Content)가 적절한 응답 상태입니다.
오리진 서버에서 리소스가 생성 된 경우 응답은 201 (생성)이어야하고 요청 상태를 설명하고 새 리소스와 위치 헤더를 참조하는 엔터티를 포함해야합니다 (섹션 14.30 참조).
응답에 적절한 Cache-Control 또는 Expires 헤더 필드가 포함되어 있지 않으면이 방법에 대한 응답을 캐시 할 수 없습니다. 그러나 303 (기타 참조) 응답을 사용하여 사용자 에이전트가 캐시 가능한 자원을 검색하도록 지시 할 수 있습니다.
POST 요청은 섹션 8.2에 설정된 메시지 전송 요구 사항을 준수해야합니다.
보안 고려 사항에 대해서는 15.1.3 절을 참조하십시오.
9.6 퍼트
PUT 메소드는 동봉 된 엔티티가 제공된 Request-URI 아래에 저장되도록 요청합니다. Request-URI가 이미 존재하는 자원을 참조하는 경우 동봉 된 엔티티는 원래 서버에있는 수정 된 버전으로 간주해야합니다. Request-URI가 기존 자원을 가리 키지 않고 요청 사용자 에이전트가 해당 URI를 새 자원으로 정의 할 수있는 경우, 오리진 서버는 해당 URI로 자원을 작성할 수 있습니다. 새로운 리소스가 생성되면 오리진 서버는 반드시 201 (Created) 응답을 통해 사용자 에이전트에게 알려야합니다. 기존 자원이 수정되면 요청 완료를 표시하기 위해 200 (OK) 또는 204 (No Content) 응답 코드를 보내야합니다. Request-URI로 자원을 작성하거나 수정할 수없는 경우, 문제의 본질을 반영하는 적절한 오류 응답이 제공되어야한다. 엔터티의 수신자는 이해하지 못하거나 구현하지 않은 Content-* (예 : Content-Range) 헤더를 무시해서는 안되며 이러한 경우 501 (구현되지 않음) 응답을 반환해야합니다.
요청이 캐시를 통과하고 Request-URI가 현재 캐시 된 하나 이상의 엔티티를 식별하는 경우 해당 항목은 오래된 것으로 취급해야합니다. 이 방법에 대한 응답은 캐시 할 수 없습니다.
POST와 PUT 요청의 근본적인 차이점은 Request-URI의 다른 의미에 반영됩니다. POST 요청의 URI는 동봉 된 엔터티를 처리 할 리소스를 식별합니다. 이 리소스는 데이터 수락 프로세스, 다른 프로토콜의 게이트웨이 또는 주석을 허용하는 별도의 엔티티 일 수 있습니다. 반대로 PUT 요청의 URI는 요청으로 둘러싸인 엔티티를 식별합니다. 사용자 에이전트는 의도 된 URI를 알고 있으며 서버는 요청을 다른 자원에 적용해서는 안됩니다. 서버가 요청을 다른 URI에 적용하기를 원하는 경우,
반드시 301 (영구적으로 이동) 응답을 보내야합니다. 그런 다음 사용자 에이전트는 요청을 리디렉션할지 여부에 대한 자체 결정을 내릴 수 있습니다.
단일 리소스는 여러 다른 URI로 식별 될 수 있습니다. 예를 들어, 기사에는 "현재 버전"을 식별하기위한 URI가있을 수 있으며, 이는 각 특정 버전을 식별하는 URI와는 별개입니다. 이 경우 일반 URI에 대한 PUT 요청으로 인해 여러 다른 URI가 오리진 서버에 의해 정의 될 수 있습니다.
HTTP / 1.1은 PUT 메소드가 오리진 서버의 상태에 미치는 영향을 정의하지 않습니다.
PUT 요청은 섹션 8.2에 명시된 메시지 전송 요구 사항을 준수해야합니다.
특정 엔터티 헤더에 다르게 지정되지 않는 한 PUT 요청의 엔터티 헤더는 PUT에 의해 생성되거나 수정 된 리소스에 적용되어야합니다.
9.7 삭제
DELETE 메소드는 오리진 서버가 Request-URI로 식별 된 자원을 삭제하도록 요청합니다. 이 방법은 오리진 서버에서 사람의 개입 (또는 다른 수단)에 의해 무시 될 수 있습니다. 오리진 서버에서 리턴 된 상태 코드가 조치가 성공적으로 완료되었음을 표시하더라도 클라이언트는 조작이 수행되었음을 보증 할 수 없습니다. 그러나 서버는 응답이 제공 될 때 리소스를 삭제하거나 액세스 할 수없는 위치로 이동시키지 않는 한 성공을 나타내서는 안됩니다.
응답에 상태를 설명하는 엔터티가 포함 된 경우 성공적인 응답은 200 (OK)이고, 조치가 아직 제정되지 않은 경우 202 (수락 됨), 조치가 제정되었지만 응답이 포함되지 않은 경우 204 (콘텐츠 없음) 여야합니다. 실체.
요청이 캐시를 통과하고 Request-URI가 현재 캐시 된 하나 이상의 엔티티를 식별하는 경우 해당 항목은 오래된 것으로 취급해야합니다. 이 방법에 대한 응답은 캐시 할 수 없습니다.