17

私はRESTfulAPIを設計しており、説明的でドキュメントを明確にするために、コンテンツタイプのhttpヘッダーを次のように宣言したいと思います。

Content-Type: application/vnd.mycorp.mydatatype+json

ここで、mycorpは私の会社に固有の識別子であり、mydatatypeは各データ型に固有です。例は次のとおりです。

Content-Type: application/vnd.ford.car+json

{
"manufactured_year": 2000
, "color": "blue"
, "hp": 160
, "model" "Focus"
, "type": "sedan"
}

このコンテンツタイプは、POSTが有効であるために必要であり、応答の一部として送信されます。ペイロード内に何を含めるべきかについてのルールを定義するための良い方法のように私には思えます。

これが良いアイデアなのか、それともIETF標準で許可されているのかについて、良いリソースを見つけることができないようです。

したがって、質問は次のとおりです。application/ vnd.mycorp.mydatatype + jsonと、単にapplication / jsonのどちらが実行可能ですか？

4

2 に答える 2

17

この質問は、REST API のバージョン管理に強く関連しています。

コンテンツ タイプは、コンテンツのタイプを定義するために使用されます。次のような標準のコンテンツ タイプを使用する場合

application/json

メッセージが JSON 形式であることをクライアントに伝えています。これは、API をバージョン管理していない、または最新バージョンのみをサポートしているすべての Web アプリケーションには十分です。クライアントが異なるバージョンの API を使用する場合、標準のコンテンツ タイプでは不十分です。次のシナリオを検討してください。

あなたの例をメッセージのバージョン 1 とします。

Content-Type: application/vnd.ford.carV1+json

{
"manufactured_year": 2000
, "color": "blue"
, "hp": 160
, "model" "Focus"
, "type": "sedan"
}

ある時点で、16 進コードを使用して色を表現することにしました。したがって、タイプのバージョン 2 を作成します

Content-Type: application/vnd.ford.carV2+json

{
"manufactured_year": 2000
, "color": "0000FF"
, "hp": 160
, "model" "Focus"
, "type": "sedan"
}

クライアントが車を要求すると、バージョンを含む正しいコンテンツ タイプが指定されます。これにより、色を 16 進コードで送信するか、名前で送信するかがアプリケーションに通知されます。

ここでは、リソースの表現をバージョン管理しています。リソース表現のバージョン管理をサポートする代替手段は、バージョンをカスタム ヘッダーとして追加することです (コンテンツ タイプの標準を維持しながら)。

Content-Type: application/json
Message-Version: 1.0
于 2014-11-23T16:00:08.417 に答える
5

間違いなく許可されています。それが良い考えかどうかは別の話です。

私の親指のルールは、それは多くのことで役立つ主要なデータ形式であり、それ自体で識別する必要があり、多くのアプリケーション間で相互運用する必要があり、間違いなくメディアタイプを与える必要があります。

ただし、それが多くのAPIの単なるメッセージであり、1つのリソース（または1つのリソース「タイプ」）にのみ有効な場合は、application/jsonを使用してください。

もちろん、YMMV。

于 2012-11-09T05:51:55.090 に答える