原文はこちら。
https://blogs.oracle.com/theaquarium/entry/content_negotiation_using_q_factors
HTTPやコンテント・ネゴシエーションを考える場合、ほとんどの場合すぐにmime-typeのことを考えるでしょう。mime-typeは確かにクライアントとサーバ間でのHTTP通信で重要なものであってそれには同意しますが、HTTPにはもっときめ細かいコンテント・ネゴシエーション・メカニズムを持っており、それはrelative quality factor、略して'q' factorといいます。'q' factorはこれまでブラウザによるサポートが少なく、ほとんどの開発者があまり知られていませんが、q-factorを使うと、クライアントが複数のmime-typeをサポートし得る場合に、JPGよりもPNGを期待する、とすれば、期待するmime-typeに対するプリファレンスをクライアントが指定することができます。この'q' factorは基本的にmime-typeに紐付く0.0から1.0までの間の数で、より大きな数であればあるほど、より好ましいmime-typeであることを示します。同様に、サーバもまた、'qs' factor、もしくはquality of source factorを指定することによって、レスポンスとして送信するにはどのmime-typeが好ましいかを示すことができます。以下のリンクは、'q' factorについてベストと思われる説明です。
'q' factorベースのネゴシエーションはRESTで非常に価値があります。より堅牢なサービスAPIを書く手助けになる可能性があります。例えば、JSONもXMLもサポートするとして、クライアントが両方をサポートしている場合には、XMLよりJSONが好ましいと伝えることができるでしょう。同様に、柔軟に複数のコンテントタイプを処理できる、より強力なクライアントを作ることができます。パブリックREST APIを作成したり、全く予測できない様々なクライアントと関わったりする場合に、こうした機能が特に役立ちます。3rdパーティのサービスを使う場合、クライアント側でも同じことが言えます。ここでよいお知らせです。JAX-RS 2とJava EE 7では強力に'q' factorベースのコンテントネゴシエーションをサポートします。Sam SepassiがJAX-RS 2.0でのコンテント・ネゴシエーションに関するすばらしい記事を先頃Upしてくれました。
https://blogs.oracle.com/theaquarium/entry/content_negotiation_using_q_factors
HTTPやコンテント・ネゴシエーションを考える場合、ほとんどの場合すぐにmime-typeのことを考えるでしょう。mime-typeは確かにクライアントとサーバ間でのHTTP通信で重要なものであってそれには同意しますが、HTTPにはもっときめ細かいコンテント・ネゴシエーション・メカニズムを持っており、それはrelative quality factor、略して'q' factorといいます。'q' factorはこれまでブラウザによるサポートが少なく、ほとんどの開発者があまり知られていませんが、q-factorを使うと、クライアントが複数のmime-typeをサポートし得る場合に、JPGよりもPNGを期待する、とすれば、期待するmime-typeに対するプリファレンスをクライアントが指定することができます。この'q' factorは基本的にmime-typeに紐付く0.0から1.0までの間の数で、より大きな数であればあるほど、より好ましいmime-typeであることを示します。同様に、サーバもまた、'qs' factor、もしくはquality of source factorを指定することによって、レスポンスとして送信するにはどのmime-typeが好ましいかを示すことができます。以下のリンクは、'q' factorについてベストと思われる説明です。
Content Negotiation Explainedこの記事では、'q' factorが多少曖昧な性質であり、これまでのWebの世界では‘q’ factorベースのネゴシエーションをサポートするブラウザが少ないけれども、Apache httpdは、長い間強力に'q' factorをサポートしてきたという事実を指摘しています。
http://www.apacheweek.com/features/negotiation
'q' factorベースのネゴシエーションはRESTで非常に価値があります。より堅牢なサービスAPIを書く手助けになる可能性があります。例えば、JSONもXMLもサポートするとして、クライアントが両方をサポートしている場合には、XMLよりJSONが好ましいと伝えることができるでしょう。同様に、柔軟に複数のコンテントタイプを処理できる、より強力なクライアントを作ることができます。パブリックREST APIを作成したり、全く予測できない様々なクライアントと関わったりする場合に、こうした機能が特に役立ちます。3rdパーティのサービスを使う場合、クライアント側でも同じことが言えます。ここでよいお知らせです。JAX-RS 2とJava EE 7では強力に'q' factorベースのコンテントネゴシエーションをサポートします。Sam SepassiがJAX-RS 2.0でのコンテント・ネゴシエーションに関するすばらしい記事を先頃Upしてくれました。
Content Negotiation in JAX-RS 2.0是非一読されて、この機能のよいユースケースがあれば利用を検討してください。
https://dzone.com/articles/content-negotiation-in-jax-rs-20