1

Content-Type具体的には、次の場合のシナリオを示します。リクエストには、ヘッダーで指定された形式（たとえば、）でフォーマットされた本文（POSTまたはPUT）を含めることができますapplication/json。ただし、URIには、応答のフォーマットを示すために通常使用される別のフォーマット（たとえば、?_format=xmlまたは）のフォーマットヒットが含まれています。resource_uri.xml私はここで3つの可能な解決策を見ます：

  1. リクエストのContent-Typeは無視され、リクエストの本文はURIで示される形式であるかのように解析されます。
  2. URIマークは無視され、要求と応答の両方がで定義されたとおりにフォーマットされていると見なされますContent-Type。
  3. リクエストの本文は、に従って解析されContent-Type、レスポンスはURIによってヒントとしてフォーマットされます。

個人的にはアプローチ＃3が好きですが、フォーマットの違いが少し心配です。ここでの通常の慣行は何ですか、異なる形式で要求と応答を行うことは許容されますか？そうでなければ、私はアプローチ＃1を好みますが、＃2は完全にオフで直感的ではないようです。ここに何か提案はありますか？

4

2 に答える 2

2

アプローチ＃3は、3つの中で唯一の正気であり、要求と応答を異なる形式にすることもできます。これは良いことです。通常、リクエストは1つの固定フォーマットであり、レスポンスはクライアントが好むサポートされているフォーマットでレンダリングできます。

アプローチ＃1は明らかにHTTPを悪用しており、日の目を見ることはありません。

アプローチ＃2も、クライアントが期待する応答形式に異なるAcceptヘッダーがあるため、非常に悪いです。

つまり、簡単に言うと、HTTPが意図した方法で（Acceptヘッダーを使用して）実行したり、URLでフォーマットをインラインで指定できるようにすることでクライアントに便利な機能を提供したりできます。両方を行うこともできます（Acceptヘッダーでフォーマットが指定されている場合はそれを使用し、そうでない場合はURLも確認してください）。

于 2012-08-16T08:31:33.600 に答える
1

アプローチ＃3は問題ありませんAccept。ヘッダーを使用して、応答形式を決定できます。このように、Content-Typeヘッダーは要求形式を設定し、Acceptヘッダーまたは_formatクエリパラメーターのいずれかが応答形式を設定します。

于 2012-08-16T08:33:44.513 に答える