2009-05-08 15 views
6

単純なデータモデルでRESTを使用する例はたくさんあります。たとえば、5つのプロパティと6つのプロパティを持つオーダーのコレクションを持つ顧客。しかし、私は、政府の調達、財務、医療記録管理などに見られる、より複雑なモデルに対してRESTを使用して視覚化するのは難しいです。大きなLOB環境にプライマリAPIとしてRESTが使用されている例がありますか?RESTは大規模な3NFモデルに適しています

おそらく、私はRESTアプローチから多すぎることを求めていますか?

答えて

6

現在、250を超えるリソースを持つRESTインターフェイスを構築しています。私が完了するまでには1000を超えることが予想されます。これは、会計、在庫、販売、労働コスト、エンジニアリングなどをカバーするERPアプリケーションです。

単一リソースのサイズまたは複雑さは直接的ではありませんRESTに関連していますが、メディアの種類の関心が高まっています。私は自分のメディアタイプを定義するルートをとることを選んだのですが、私もクライアントを構築していて、インターフェイスは一般消費用ではありません。あなたの状況に合った最良のメディアタイプを選択するのはおそらく、RESTインターフェースを設計する上で最も難しい部分の1つです。

残念ながら、ほとんどの人はメディア/タイプの決定に挑戦し、ジェネリックapplication/jsonまたはapplication/xmlを選択し、ブラウザでダウンロードされたjavascriptを使用してフォーマットを解釈しているようです。あなたが持っている唯一のクライアントがブラウザであり、他の誰かがあなたのインターフェースを再利用することを望まない限り、それは機能します。私にとっては、RESTの主な目標の1つ、すなわちゆるやかな結合と標準化されたフォーマットのために予期せぬ再使用を犠牲にしているようです。

このことをさらに説明するために、application/jsonまたはapplication/xmlをクライアントアプリケーションに配布する場合を考えてみましょう。クライアントアプリケーションがその汎用フォーマットに達し、特定のデータを取得するとすぐに、クライアントとサーバーの間に隠れた結合が作成されます。代わりにメディアフォーマット "application/vnd.mycompany.myformat + xml"を使用する場合は、クライアントとの契約を明示的に定義しています。これは、フォーマットを変更して "application/vnd.mycompany.myformatV2 + xml"を作成するオプションがある場合に大きな利点があります。

人々はRESTを緩やかに指定されたインターフェイスと認識しますが、実際はそうではありません。 RESTインターフェースは、それが返す正確なメディア・タイプに非常に明示的でなければなりません。メディアタイプは契約です。 application/xmlを受け取ってクライアントコードを使用して/ Customer/Nameを引き出すと、契約が破棄されます。契約の詳細は、クライアントにコンパイルされていないため、「アプリケーション/ XML」を消費することができるJavaScriptをダウンロードし使用

Webアプリケーション。しかし、クライアントの振る舞いは、javascriptがあらかじめプログラムされているものを実行することに非常に制限されています。残念なことに、大部分の公開RESTfulインターフェイスはこの制約を無視し、不特定の契約に密接に結びついたクライアントを構築します。だからTwitterがそのフォーマットを変えると、多くのクライアントが壊れてしまう。

+0

これは非常にインターセッティングされているように聞こえて、まさに私が探していたものです。しかし、私はあなたが何を意味するのかはっきりしていません "ほとんどの人々はメディア/タイプの決定に悩まされているようです"どのように自分のメディアの種類のヘルプを定義するのだろうか? –

+0

私はこの回答を2回以上upvoteしたいと思います! – migu

0

RESTは、到達したいデータを記述するのに合理的な説明的なパスがある限り適切です。

達成しようとしていることがAPIを公開している場合、RESTはRESTとは感じられませんが、RESTの考え方を使用して開発されたAPIは本当にうまくいっています。

あなたの説明から、構造の複雑さにかかわらず、RESTに非常にうまく対応するデータで作業しています。 RESTは公開スキーマを禁止しないので、同様に考慮する必要があります。

5

RESTはアーキテクチャスタイルであり、データの表現ではありません。一般的に今日のデータは、XMLやJSONのいずれかで表現されています。これはバトルテストされており、あなたが参照している大規模な複雑なモデルを簡単にサポートできます。

最も基本的なフォームでは、RESTは単純に "リソース"を制御するHTTP動詞です。そのリソースの表現は、必要なだけシンプルに、または複雑にすることができます。 CRUDとリスト操作は最も単純です。さらに複雑なAPIをこのコンテキスト内で簡単に生成することもできます。

+0

+1、提供する偉大なパースペクティブの – cgp

+0

ニースの答え - 簡潔な! –

関連する問題