web-dev-qa-db-ja.com

RESTful APIメソッド。 HEAD＆OPTIONS

PHPのアプリケーション用のRESTful APIモジュールを書いていますが、HEADとOPTIONSの動詞が少し混同されています。

  • OPTIONS 特定のリソースで利用可能なHTTP動詞を取得するために使用しますか？
  • HEAD特定のリソースが利用可能かどうかを判断するために使用されますか？

誰かがこれらの動詞を明確にすることができたら*、それは大歓迎です。

*説明は、HTTP動詞を再利用するRESTful APIアーキテクチャに関するものでした。それ以来、HEADとOPTIONSの両方をnotに変更し、代わりにHTTPアプリケーションのように予測どおりに動作することに気付きました。ああ、2年後にどのように成長するか。

phpapihttprest
76
Dan Lugg

通り： http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.2オプション

OPTIONSメソッドは、Request-URIで識別されるリクエスト/レスポンスチェーンで利用可能な通信オプションに関する情報のリクエストを表します。このメソッドにより、クライアントは、リソースアクションを暗示したり、リソースの取得を開始したりすることなく、リソースに関連付けられたオプションや要件、またはサーバーの機能を決定できます。

このメソッドへの応答はキャッシュできません。

OPTIONS要求にエンティティ本体が含まれる場合（Content-LengthまたはTransfer-Encodingの存在によって示される）、メディアタイプはContent-Typeフィールドによって示されなければなりません。この仕様ではそのようなボディの使用を定義していませんが、HTTPの将来の拡張ではOPTIONSボディを使用してサーバー上でより詳細なクエリを作成する可能性があります。そのような拡張をサポートしていないサーバーは、リクエストボディを破棄してもよい[MAY]。

Request-URIがアスタリスク（「*」）である場合、OPTIONS要求は特定のリソースではなくサーバー一般に適用されることを意図しています。サーバーの通信オプションは通常リソースに依存するため、「*」リクエストは「ping」または「no-op」タイプのメソッドとしてのみ有用です。クライアントがサーバーの機能をテストできるようにするだけです。たとえば、これを使用して、HTTP/1.1準拠（またはその欠如）のプロキシをテストできます。

Request-URIがアスタリスクでない場合、OPTIONS要求は、そのリソースと通信するときに使用可能なオプションにのみ適用されます。

200応答には、サーバーによって実装され、そのリソースに適用可能なオプション機能（たとえば、許可）を示すヘッダーフィールドを含める必要があります（おそらく、この仕様で定義されていない拡張機能を含む）。応答本文には、通信オプションに関する情報も含める必要があります。このような本文の形式は、この仕様では定義されていませんが、将来のHTTPの拡張機能で定義される可能性があります。コンテンツネゴシエーションを使用して、適切な応答形式を選択できます。応答本文が含まれていない場合、応答には、フィールド値が「0」のContent-Lengthフィールドを含める必要があります。

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

9.4 HEAD

HEADメソッドは、サーバーが応答でメッセージ本文を返してはならないことを除いて、GETと同じです。 HEAD要求への応答でHTTPヘッダーに含まれるメタ情報は、GET要求への応答で送信された情報と同一である必要があります。このメソッドは、エンティティ本体自体を転送せずに、リクエストによって暗示されるエンティティに関するメタ情報を取得するために使用できます。このメソッドは、ハイパーテキストリンクの有効性、アクセシビリティ、最近の変更をテストするためによく使用されます。

HEAD要求への応答は、応答に含まれる情報を使用して、以前にキャッシュされたエンティティをそのリソースから更新できるという意味で、キャッシュ可能です。キャッシュされたエンティティが現在のエンティティと異なることを新しいフィールド値が示す場合（Content-Length、Content-MD5、ETag、またはLast-Modifiedの変更によって示される）、キャッシュはキャッシュエントリを失効として扱わなければなりません。

46
sdolgy

OPTIONSメソッドは[〜＃〜] api [〜＃〜]（メソッド/コンテンツタイプ）に関する情報を返します

HEADメソッドは、resource（version/length/type）に関する情報を返します

サーバー応答

[〜＃〜] options [〜＃〜]

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

[〜＃〜] head [〜＃〜]

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アーキテクチャにどのように適合するかについてのすてきな簡潔な記事です。

48
Yuriy Kvartsyanyy

OPTIONSは、「このリソースに許可されるメソッド」などの情報を示します。

HEADは、GETリクエストを行った場合に取得するHTTPヘッダーを取得しますが、本文は取得しません。これにより、クライアントはキャッシュ情報、返されるコンテンツタイプ、返されるステータスコードを判別できます。可用性はほんの一部です。

22
Quentin