問題タブ [content-negotiation]

キャッシングがコンテンツネゴシエーションベースのAPIでどのように機能するのか疑問に思っています。XMLまたはJSONでリソースを取得するため、URIは同じになります。次に例を示します。

このサービスは、Acceptタイプのヘッダーに基づいてJSON/XMLを返します。キャッシュはどれくらい賢いですか？

例えば：

• 1つのクライアントがAcceptタイプを使用してこれを要求し、XMLを返す場合。
• 応答は、Webサーバーによってたとえば1分間キャッシュされます。
• 2番目のクライアントは、Acceptタイプを使用して同じリソースを要求し、JSONを返します

キャッシングチェックは/コンテンツタイプを受け入れますか？または、これにより、サーバーがキャッシュしたものであるため、JSONリクエスターがXMLデータを取り戻すことになりますか？これがすでに処理されていることは明らかだと思います。そうでない場合は、URIに.xml / .jsonを含めるというかなり大きな議論ではありませんか？

私の質問は基本的に、標準のキャッシュ技術を使用しながらコンテンツネゴシエーションを安全に使用できるかということだと思います。

アプリケーション/xhtml+xml の正しいコンテンツ タイプを使用して、Rails アプリで XHTML コンテンツを適切に提供しようとしています。理想的には、コンテンツ ネゴシエーションを使用して、IE ユーザーもサイトを使用する機会を得られるようにします。

Rails によって生成されたすべての HTML が XHTML 1.0 Transitional でマークされていることを考えると、Rails がマークアップを XHTML として提供するための明らかなオプションがないことに少し驚いています。http://blog.codahale.com/2006/05/23/rails-plugin-xhtml_content_type/を見つけましたが、1.1.2 用のようで、2.3.8 では正しく動作しません。

ここで何かを見逃しましたか？

クライアントがサポートされていないメディアタイプのデータをHTTPサーバーに送信すると、サーバーはステータス「415サポートされていないメディアタイプ」で応答します。しかし、どのメディアタイプがサポートされているかをクライアントに伝えるにはどうすればよいでしょうか。そのための標準的な方法、または少なくとも推奨される方法はありますか？それとも、応答本文にテキストとして書き込まれるだけでしょうか。

Accept ヘッダーと withFormat メソッドを使用して、サービスでコンテンツ ネゴシエーションを使用しています。直面している問題は、Accept ヘッダーにサービスでサポートされていないタイプがある場合に 406 http ステータスを返したいということです。 ...これをどのように行うかについて、誰かアイデアをいただけますか?

最近のプロジェクトでは、応答用に XML と別の形式をサポートしたいと考えていました。

ただし、Accept ヘッダーを制御できませんでした。したがって、代わりにリクエストパラメーターを使用するように ContentNegotiatingViewResolver を構成しました。

しかし、@ResponseBody と HttpMessageConverter の実装を使用して、維持する必要のあるコードの量を簡素化できるかどうか疑問に思っていました。

ただし、Accept ヘッダーの代わりに要求パラメーターがコンテンツ ネゴシエーションに使用されるようにする同様の方法はありますか?

JAX-RS（特にJersey）の自動HTTPコンテンツネゴシエーション、つまり「Accept」や「Content-Type」ヘッダーによってリソースをルーティングする機能を楽しんでいます。しかし、対立がある場合、それでは十分なコントロールが得られない場合があることに気づきました。

たとえば、次のエンドポイントについて考えてみます。

FirefoxとChromeで異なる結果が得られます。FirefoxはHTMLエンドポイントにマップされますが、ChromeはエンドポイントURLにそれぞれ移動するとXMLエンドポイントをトリガーします。それらの違いは、AcceptヘッダーにリストされているMIMEタイプの順序です。Chromeは以下を送信します。

Firefoxでは、HTMLが最初にリストされます。

すべてが同じように重み付けされている場合、最初のエントリと一致することは論理的であるように思われます。しかし、私の場合、私は私が望むものとは異なる結果を得ているので、タイブレークのためのより良い方法を決定するのは素晴らしいことです。

私の質問：これらのメソッドにヘッダー情報を挿入し、メディアタイプ処理を自分で実行する以外に、同点の場合にいわば「重みを微調整」する方法はありますか？たとえば、常にXMLをHTMLよりも優先するように指示できますか？私のRESTfulクライアントは、どのタイプを返したいかについて非常に明確ですが、ブラウザーはAcceptヘッダーでずさんなことで有名です。（個人的には、HTMLをXMLより少し上に重み付けする必要があると思います。これはユーザーが期待することですが、少し遅れています。）

または、一元化された場所で1回だけ独自のカスタムコンテンツネゴシエーションを実行できますか？私はこのロジックを手動で書き出すことに反対していませんが、それが私のリソースのすべてのインスタンスに適用することを意味する場合はそうではありません。JAX-RSには、ルーティングされる前にリクエストを微調整するためにパイプラインにフィルターを追加するという概念がありますか？

私はJSONPを使用してSpringMVCのコントローラーサービスを呼び出しています。コールバックにラップされた結果を返すカスタムフィルターがあります。この例、http：//jpgmr.wordpress.com/2010/07/28/tutorial-implementing-a-servlet-filter-for-jsonp-callback-with-springs-delegatingfilterproxy/を使用しました。ContentNegotiatingViewResolverも使用していますが、結果はコールバックでXMLを返し続けます。なぜそれを続けるのでしょうか？

サーブレット-context.xml

次の質問の情報に基づくREST Content-Type: Should it be based on extension or Accept header? 、カスタム URI または Accept ヘッダーの指定のいずれかが、REST 風の Web サービスがクライアントの応答形式を決定するための「許容される」(しゃれを意図した) メソッドであることを認識しています。

ただし、多くの有名企業は API でカスタム URI メソッドを使用しているようです。ある方法が他の方法よりも優れている点は何ですか?