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）。応答本文には、もしあれば、通信オプションに関する情報も含まれる必要があります（SHOULD）。そのような本体の形式は、この仕様では定義されていませんが、HTTPの将来の拡張によって定義される可能性があります。コンテンツネゴシエーションは、適切な応答フォーマットを選択するために使用される場合があります。応答本文が含まれていない場合、応答にはフィールド値「0」のContent-Lengthフィールドを含める必要があります。

Max-Forwardsリクエストヘッダーフィールドを使用して、リクエストチェーン内の特定のプロキシをターゲットにすることができます。プロキシが、リクエストの転送が許可されているabsoluteURIでOPTIONSリクエストを受信した場合、プロキシはMax-Forwardsフィールドを確認する必要があります。Max-Forwardsフィールド値がゼロ（ "0"）の場合、プロキシはメッセージを転送してはならない（MUST NOT）。代わりに、プロキシは独自の通信オプションで応答する必要があります（SHOULD）。Max-Forwardsフィールド値がゼロより大きい整数の場合、プロキシはリクエストを転送するときにフィールド値をデクリメントする必要があります。リクエストにMax-Forwardsフィールドが存在しない場合、転送されるリクエストにMax-Forwardsフィールドを含めてはなりません（MUST NOT）。

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ヘッダーを取得しますが、本文は取得しません。これにより、クライアントはキャッシュ情報、返されるコンテンツタイプ、返されるステータスコードを決定できます。可用性はそのほんの一部です。