RESTful API 메서드 헤드 및 옵션

저는 PHP로 애플리케이션을위한 RESTful API 모듈을 작성하고 있으며 동사 HEAD와 OPTIONS.

• OPTIONS  주어진 리소스에 대해 사용 가능한 HTTP 동사를 검색하는 데 사용됩니까?
• HEAD 주어진 리소스를 사용할 수 있는지 여부를 결정하는 데 사용됩니까?

누군가이 동사들을 명확히 * 할 수 있다면, 그것은 대단히 감사 할 것입니다.

_{* 설명은 HTTP 동사의 용도를 변경하는 RESTful API 아키텍처에 관한 것입니다. 나는 이후 모두 그 실현에 왔어요 HEAD하고 OPTIONS해야 하지 다시 작정, 그리고 어떤 HTTP 응용 프로그램이 정상적으로 대신 예상대로 작동합니다. 오, 우리가 2 년 안에 어떻게 성장하는지.}

기준 : http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.2 옵션

OPTIONS 메소드는 Request-URI로 식별되는 요청 / 응답 체인에서 사용할 수있는 통신 옵션에 대한 정보 요청을 나타냅니다. 이 방법을 사용하면 클라이언트가 리소스 작업을 암시하거나 리소스 검색을 시작하지 않고도 리소스와 관련된 옵션 및 / 또는 요구 사항 또는 서버의 기능을 결정할 수 있습니다.

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

OPTIONS 요청에 엔티티 본문이 포함 된 경우 (Content-Length 또는 Transfer-Encoding의 존재로 표시됨) 미디어 유형은 Content-Type 필드로 표시되어야합니다. 이 사양은 이러한 본문에 대한 용도를 정의하지 않지만 HTTP에 대한 향후 확장은 OPTIONS 본문을 사용하여 서버에서 더 자세한 쿼리를 만들 수 있습니다. 그러한 확장을 지원하지 않는 서버는 요청 본문을 버릴 수 있습니다.

Request-URI가 별표 ( "*") 인 경우 OPTIONS 요청은 특정 자원이 아닌 일반적으로 서버에 적용됩니다. 서버의 통신 옵션은 일반적으로 리소스에 따라 다르므로 "*"요청은 "ping"또는 "no-op"유형의 방법으로 만 유용합니다. 클라이언트가 서버의 기능을 테스트하도록 허용하는 것 외에는 아무것도하지 않습니다. 예를 들어 HTTP / 1.1 준수 (또는 부족)에 대해 프록시를 테스트하는 데 사용할 수 있습니다.

Request-URI가 별표가 아닌 경우 OPTIONS 요청은 해당 리소스와 통신 할 때 사용할 수있는 옵션에만 적용됩니다.

200 응답은 서버에 의해 구현되고 해당 자원에 적용 할 수있는 선택적 기능 (예 : 허용)을 나타내는 헤더 필드를 포함해야합니다 (이 사양에 정의되지 않은 확장을 포함). 응답 본문이 있으면 통신 옵션에 대한 정보도 포함해야합니다 (SHOULD). 이러한 본문의 형식은이 사양에 정의되어 있지 않지만 향후 HTTP 확장에 의해 정의 될 수 있습니다. 콘텐츠 협상은 적절한 응답 형식을 선택하는 데 사용될 수 있습니다. 응답 본문이 포함되지 않은 경우 응답은 필드 값이 "0"인 Content-Length 필드를 포함해야합니다.

Max-Forwards 요청 헤더 필드는 요청 체인의 특정 프록시를 대상으로하는 데 사용될 수 있습니다. 프록시가 요청 전달이 허용 된 absoluteURI에 대한 OPTIONS 요청을 수신하면 프록시는 Max-Forwards 필드를 확인해야합니다. Max-Forwards 필드 값이 0 ( "0")이면 프록시는 메시지를 전달하지 않아야합니다. 대신 프록시는 자체 통신 옵션으로 응답해야합니다. Max-Forwards 필드 값이 0보다 큰 정수이면 프록시는 요청을 전달할 때 필드 값을 줄여야합니다. 요청에 Max-Forwards 필드가없는 경우 전달 된 요청은 Max-Forwards 필드를 포함하지 않아야합니다.

9.4 헤드

HEAD 메서드는 서버가 응답에서 메시지 본문을 반환하지 않아야한다는 점을 제외하고 GET과 동일합니다. HEAD 요청에 대한 응답으로 HTTP 헤더에 포함 된 메타 정보는 GET 요청에 대한 응답으로 전송 된 정보와 동일해야합니다 (SHOULD). 이 방법은 엔티티 바디 자체를 전송하지 않고 요청이 암시하는 엔티티에 대한 메타 정보를 얻는 데 사용할 수 있습니다. 이 방법은 유효성, 접근성 및 최근 수정을 위해 하이퍼 텍스트 링크를 테스트하는 데 자주 사용됩니다.

HEAD 요청에 대한 응답은 응답에 포함 된 정보가 해당 리소스에서 이전에 캐시 된 엔티티를 업데이트하는 데 사용될 수 있다는 점에서 캐시 가능할 수 있습니다. 새 필드 값이 캐시 된 엔티티가 현재 엔티티와 다르다는 것을 나타내는 경우 (Content-Length, Content-MD5, ETag 또는 Last-Modified의 변경으로 표시됨) 캐시는 캐시 항목을 오래된 것으로 취급해야합니다.

OPTIONS메서드는 API 에 대한 정보를 반환 합니다 (메서드 / 콘텐츠 유형).

HEAD메서드는 리소스 에 대한 정보 (버전 / 길이 / 유형)를 반환합니다.

서버 응답

옵션

HTTP/1.1 200 OK
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:24:43 GMT
Content-Length: 0

머리

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:12:29 GMT
ETag: "780602-4f6-4db31b2978ec0"
Last-Modified: Thu, 25 Apr 2013 16:13:23 GMT
Content-Length: 1270

• OPTIONS 리소스가 지원하는 HTTP 메서드 식별, 예를 들어 PUT를 통해 삭제하거나 업데이트 할 수 있습니까?
• HEAD자원이 변경되었는지 확인합니다. 이것은 리소스의 캐시 된 버전을 유지할 때 유용합니다.
• HEAD 비용이 많이 드는 검색을 수행하기 전에 리소스에 대한 메타 데이터 (예 : 미디어 유형 또는 크기) 검색
• HEAD, OPTIONS리소스가 존재하고 액세스 가능한지 테스트합니다. 예를 들어, 응용 프로그램에서 사용자가 제출 한 링크의 유효성 검사

다음 은 HEAD 및 OPTIONS가 RESTful 아키텍처에 어떻게 적용되는지에 대한 훌륭하고 간결한 기사입니다.

OPTIONS는 "이 자원에 대해 허용되는 메소드"와 같은 것을 알려줍니다.

HEAD는 GET 요청을 한 경우 얻을 수있는 HTTP 헤더를 가져 오지만 본문은 없습니다. 이를 통해 클라이언트는 캐싱 정보, 반환되는 콘텐츠 유형, 반환 될 상태 코드를 결정할 수 있습니다. 가용성은 그것의 작은 부분 일뿐입니다.