問題タブ [content-negotiation]

Zend Framework 2 では、コンテンツ ネゴシエーションはビュー レイヤーで行われますが、これにはかなり満足しています。私のコントローラーの例：

これにより、view.phtml テンプレートがレンダリングされて html が返されるか、ユーザー オブジェクトが JSON 応答に変換されます。いわゆるビュー戦略は、リクエストに基づいてレスポンスをレンダリングする方法を決定します。

私の webapp での「REST」アプリケーション フロー

このタイプのコンテンツ ネゴシエーションは、多くのユース ケースで非常にうまく機能します。

1. /userまたはindexAction()、ユーザーの配列を返します => JSON の html が可能です。
2. /user/1またはviewAction()ユーザーオブジェクトを返します=> htmlまたはJSONが可能です（上記の例）;
3. /user/1/updateまたはupdateAction()htmlフォームを返します。エラーが存在する場合、この URL への POST は html または JSON を返します。または、成功するとリダイレクトされviewAction()、ユーザーの新しいバージョンが返されます => html と JSON が再び可能になります。
4. /user/createまたはcreateAction()htmlフォームを返します。エラーが存在する場合、この URL への POST は html または JSON を返します。または、成功するとviewAction()、作成されたばかりのユーザーにリダイレクトされます => html と JSON が再び可能になります

私の質問

コントローラー層でコンテンツ ネゴシエーションが「必須」となるユース ケースがいくつかあります。いくつかの可能性を見落としているかどうかはわかりません。たとえば、次の場合に使用できるオプションはありますか?

1. ユーザーの削除: に POST します/user/1/delete。HTML ビューの場合は、ユーザーのリストにリダイレクトされます (削除されたユーザーは表示されません)。JSON 応答が必要な場合は、200 OK と、削除が成功したというメッセージを含む JSON オブジェクトを返します。
2. ブログ記事にコメントを投稿します。HTML ビューの場合、コメントが追加されている投稿にリダイレクトされます。JSON 応答を要求する場合は、200 OK と、配置したばかりのコメントを含む JSON オブジェクトを返す必要があります。

私の目標は、ビュー レイヤーに既に存在するコンテンツ ネゴシエーションを複製しないことです。また、2 つの可能な応答 (JSON と html) があるため、コントローラーがより太くなりますが、それが唯一のケースではない可能性があります。後で XML や別の形式をサポートしたい場合は、それらの応答タイプのすべてのアクション スイッチを用意します。

ヘッダー 'Content-type: application/json' が送信されると、Rails はいくつかのレベルで動作を変更します。

• 送信された投稿の本文は、単なる文字列パラメーターではなく、json として解析されます
• config/initializers/wrap_parameters.rb の wrap_parameters :format => [:json] は、投稿された言及されたパラメーターを解析するときに使用されます (したがって、ルート要素の有無にかかわらず json を送信できます)

(外部) クライアントが正しいヘッダーを渡すことを信頼できない場合はどうすればよいですか? つまり、クライアントが実際に渡さなくても、クライアントが常に'Content-type: application/json' ヘッダーを渡すかのようにアプリケーションを動作させたいですか?

MultiViews を備えた Apache サーバーがあります。これが私のディレクトリ レイアウトです。

私の index.xml ファイルでは、XSL を参照しています。

XSL では、CSS を参照します。

このアプローチは、私が試したどのブラウザーでも機能しません。

Firefox-16.0.1 では、次のメッセージが表示されます。

HTTP 会話をデバッグすると、Firefox が次のメッセージを送信していることに気付きました。

Firefox はあらゆる種類のコンテンツを要求しているため、Apache は /style.css を送信することを選択します。

特定のコンテンツ タイプを必要とする Web ブラウザは、それらのコンテンツ タイプに対して明示的な Accept ヘッダーを送信することを期待しています。

Accept 制約を取り除くことを明示的に文書化した他の 2 つの文書を見つけたとき、私はバグを提出する準備ができていました。

• XSLT を取得するための Accept ヘッダーの冗長性を減らします
• スタイルシート リンク ヘッダーは公式の XSLT メディア タイプをサポートしていません

ファイル名に拡張子を入れることでこれを回避できますが、これはW3C ブログで説明されているように、画像のコンテンツ ネゴシエーションと同じように機能するはずです。利点は、ドキュメントを更新することなく、後で新しいコンテンツ タイプを追加できることです。

これはバグですか、それとも何か間違っていますか?

リソースのさまざまな表現の提供に関するベスト プラクティスについて質問があります。私の使用例は、さまざまなコンテンツ タイプ (xml や json など) でオブジェクトの表現を単純に提供するよりも少し複雑です。

背景: この API は、コンテンツ管理システム用です。API の重要な側面の 1 つは、ユーザーがドキュメントの zip ファイルとそのすべての依存関係 (リンクされた画像、およびその他のドキュメント) を要求できることです。

たとえば、ドキュメント/rest/all-documents/{doc-id}の XML 表現を返すドキュメントにアクセスする場合があります。

彼らがドキュメントの zip とそのすべての依存関係を取得する方法を設計するとき、私はいくつかのオプションを考え出しました:

1. コンテンツ ネゴシエーションを使用し、Acceptヘッダーをベンダー固有のものに設定します。つまり、vnd.company.compiled-doc+zip です。
2. 次のようなサブコレクションを使用します/rest/all-documents/{doc-id}/export（エクスポートは動詞なので、これが十分に標準化されているかどうかはわかりません）
3. 読み取り専用だった別の URI でサービスを提供します。/rest/compiled-documents/{doc-id}

この問題は何度も発生する可能性があるため、API のこの部分を設計する最善の方法を判断するのに非常に苦労しています。これまでのところ、私はオプション 3 に傾いていますが、

ありがとう、

ケーシー

列挙型を返す RESTful サービスがあります。

列挙型の値として整数を返すか文字列を返すかを考えていたとき、文字列を返すかどうかはクライアントのロケールに依存することに気づきました。

では、REST でローカリゼーションをどのように扱うべきでしょうか? ロケールは conneg の一部ですか?

.NET MVC 4 を使用して C# で実装されている Web サービスがありますが、Accept: application/json ヘッダーを送信しているにもかかわらず、何らかの理由で常に XML 形式でデータが返されます。何が間違っている可能性がありますか？

前もって感謝します

更新：コントローラーコードは次のようになります

更新 2 : 生のリクエストとレスポンス

リクエスト

応答

ブラウザが Web サイトに送信する Accept_Language に反応したいと思います。

ブラウザーが Web サイトに送信する可能性のある使用可能なすべての Accept_Languages の信頼できるリストをどこで入手できるか知っている人はいますか?

どうもありがとうございました！

SpringMVCを使用して標準のJavaWebアプリケーションを開発し、最近3.0.6から3.2.0へのアップグレードを試みました。ほぼすべてのサーブレット応答はJSPまたはJsonビューですが、拡張子が「pdf」のpdfリクエストであるものもあります。

Spring 3.0.6では、SpringMVCドキュメントから取得したこの設定が行われました。

これは、XMLViewResolverと組み合わせて正常に機能しました。

3.2.0にアップデートした後、失敗があります：

ドキュメントといくつかのブログを調査した後、この構成は機能しているようです。

しかし、この構成を使用して新しいSpring MVCテストフレームワークを実行しようとしましたが、ClassCast例外が再度発生したため、テストフレームワークはアプリケーションの実行時と同じようにBeanを初期化していないようです... Spring 3,2でContentNegotiatingViewResolverを堅牢な方法で構成する方法の明確な説明はありますか？ありがとう

リチャード

コントローラの外部で発生する可能性のあるエラー（HTTP 404など）をグローバルに処理するために、web.xmlに次のようなエントリがあります。

私のErrorControllerには、次のような対応するメソッドがあります。

私が直面している問題はContentNegotiationManager、この場合、構成したメッセージコンバーターとメッセージコンバーターが使用されていないことです。リクエストがエラーページにリダイレクトされているため、コンテンツネゴシエーションで使用されていた元のリクエストの属性が失われ、これは完全に別個のリクエストとして扱われると思われます。（つまり、/ mycontroller / badresource.json-> / errors / 404（ファイル拡張子なし）の元のリクエスト）

このようなエラーハンドラーで、元のリクエストでリクエストされた適切なコンテンツタイプを決定および/または応答する方法はありますか？

REST-ful Web サービスを考えると

Content-Type の Product XML ドキュメントを返す

私も応援しなきゃ

(x-esvc はカスタム MIME タイプです。製品と価格は 2 つのサブタイプであり、+xml はRFC 3023に従って XML ベースの形式であることを示しています)

問題は、この 2 番目の形式が独自の Web サービスを持つべきかどうかです。

...または、コンテンツ ネゴシエーションと Accept HTTP ヘッダーを使用して、既存の製品 Web サービスの 2 つの形式を区別する必要があるかどうか?

関連する実際のエンティティ (製品) は 1 つだけであり、「価格」は OO 用語による依存オブジェクトのリストであることに注意してください。ただし、どちらの場合も同じ識別子を使用できます。

問題を定式化する別の方法は、「価格」が同じリソースの異なる表現と見なすことができるかどうか、または情報が異なる場合に別のリソースと見なす必要があるかどうかです。

コンテンツ ネゴシエーションは通常、同じ画像に対して JPG と PNG などの異なる技術フォーマットを区別するために使用されることを知っています。つまり、情報は同じですが、形式が異なります。この場合、コンテンツ ネゴシエーションは、同じエンティティの異なる情報を区別するために使用されます。

これは、コンテンツ ネゴシエーションと Accept HTTP ヘッダーを REST-ful Web サービスで有効に使用できるでしょうか?