5

序文：

HTTP と REST について多くのことを読んだ後、狡猾なコンテンツ ネゴシエーション スキームを考案するのに数時間を費やしました。Web API が単一の URL から XML、JSON、および HTML を提供できるようにします。ご存知のように、リソースには 1 つの URL のみを含める必要があり、Acceptヘッダーを使用してさまざまな表現を要求する必要があります。Web がその実現に 20 年もかかった理由を疑問に思うようになります。

そして、それは現実があなたの顔を平手打ちするときです。

したがって、ブラウザー (およびデバッグしようとしているユーザー) がサービスに目的のコンテンツ タイプを強制的に提供するのを助けるために、すべての自尊心のある REST エバンジェリストが軽蔑することを行います:ファイル名拡張子。

地獄での永遠の苦痛にもかかわらず、次のContent-Location+の使用は.ext許容されますか?

/users/:loginnameたとえばにユーザーがいるとします/users/bob。Acceptこれは、適切なヘッダーを設定できるあらゆるものの API エンドポイントになります。ただし、可能な限りContent-Type(または少なくとも一部) は、別のアクセス方法を許可します。これは、ファイルタイプのサフィックスが付いた URL です。たとえば/users/bob.html、HTML 表現の場合。ログイン名にピリオド/ドットが含まれることはないと仮定しましょう (これは大きな仮定です) 。

リクエスト：

GET /users/bob.json HTTP/1.1  
Host: example.com

応答：

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 14
Content-Location: /users/bob

{"foo": "bar"}

これにより、(この場合) ユーザー情報にアクセスする別の方法をエンコードできます。たとえば、ユーザー ページへのリンクは<a href="/users/bob.html">Bob</a>. vCard へのリンク (ユーザーをアドレス帳/Outlook/その他に追加するため) は<a href="/users/bob.vcf">Bob</a>.

私が見逃した落とし穴はありますか？これの長所/短所は何ですか？

編集：これは、私が気付くのに少し遅れてポップアップしました。主題に触れていて本当に役に立ちますが、私が探しているものとは違うと思います...

4

2 に答える 2

1

私の知る限り、あなたは Content-Location をまったく間違った方法で使用しています。より具体的な URI を指す必要があります。

于 2013-04-09T05:35:37.827 に答える
0

RFC 2616 によると:

The Content-Location entity-header field MAY be used to supply 
the resource location for the entity enclosed in the message 
when that entity is accessible from a location separate from 
the requested resource's URI.

と

The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource 
corresponding to this particular entity at the time of the request.

したがって、一般的に、はい、 Content-Location ヘッダーを使用して元のリソースを識別できます。拡張サフィックスを使用する主な欠点は、別の URL を作成することです。たとえば、/users/bob、/users/bob.vfc、/users/bob.html は 3 つの異なるリソースです。

于 2013-04-08T15:46:33.183 に答える