1

私は、すべてのクライアント要求に対して単一のゲートウェイを備えたサービス指向アーキテクチャーを持っています。ゲートウェイが整頓されていて、すべての「内部」サービスを隠し、ディスパッチャーおよび自家製のロードバランサーとして機能するため、これが気に入っています。

ただし、私の設計のため、クライアントは「1つの」リソースについてしか知りません。また、JSONで定義された操作とそのパラメーターを要求したメッセージを送信する必要があります。

{
    "operation" : "Login",
    "parameters" :
    {
         "username" : "John",
         "password" : "1234"
    }
}

私のアーキテクチャはRESTfulではないので、私は悲しいべきですか？RESTが規定するようにHTTPを活用していませんか？批評してください。

4

2 に答える 2

2

「悲しい」が正しい言葉かどうかはわかりませんが、RESTを支持する議論の1つは、特にHTTPを「適切に」使用して実装された場合、次のことを無料で提供することです（Fieldingの論文から引用） ）：：

  • クライアントとサーバーの相互作用、UIをデータストレージから分離
  • ステートレスサーバー、信頼性とスケーラビリティの向上
  • クライアントキャッシュ、一部のネットワークトラフィックを削減
  • 統一されたインターフェース、実装を提供するサービスから切り離す
  • 階層化システム。各コンポーネントは、そのすぐ下またはすぐ上のコンポーネントのみに関係します。
  • リソースの観点から考える表現オリエンテーション
  • HATEOAS、アプリケーションは基本的にリンクをナビゲートします
  • 動詞の数が少ない制約付きインターフェース（例：GET、PUT、POST、DELETE、その他約3つのみ）

RESTの代わりにSOAPまたは別のRPCソリューションを使用する場合、理論的には、これらの特性のすべてではなく一部を放棄することになります。あなたはクライアントのキャッシュ可能性をあきらめているかもしれません、そしてあなたは手続き的に考えています、そしてあなたはおそらくRESTafariansがティーに利用するすべての安全性とべき等条件を使うことができないでしょう。

RESTfulサービスは非常に人気があり、偶然ではありません。しかし、それは、 RESTfulサービスを構築する必要があるということですか、それとも非RESTfulサービスは本質的にはるかに悪いということですか？私はそうは思わない。私は2つの異なる会社のためにいくつかのRESTfulSOAを実行しましたが、SOAP（最近はかさばるように見えます）とあなたのような自家製のAPI（エレガントであっても標準ではありません）を好みますが、私はしません他のアプローチを却下し、それらを劣ったものとして却下します。

独自のAPIを使用し、200と404のみを返し、GETを使用してすべてを実行する場合、APIは概念的に単純であり、おそらく問題なく機能します。ただし、さまざまなメディアタイプが必要であり、コレクションの追加、削除、作成、更新が頻繁に行われるコレクションを含む永続的なストレージ要件がある場合は、最新のRESTful API設計を学ぶことで、少なくとも新しい考え方が生まれます。

結論としては、他の人がやっているので、RESTに行かなくてはならないという気持ちも悲しみもありません。しかし、利点は現実のものであり、RESTは単なる誇大宣伝ではありません。

于 2011-07-26T05:04:50.317 に答える
1

いいえ。基本的に、XMLの代わりにJSONを使用する自家製のSOAPスタイルのRPCがあります。

SOAPスタックを使用するのではなくJSONでそれを再発明する価値があるかどうかを尋ねるかもしれませんが、JavaScriptと話している場合は、SOAPよりも使いやすいだけでなく、SOAP標準/ツールセットに準拠する負担もありません。 。

それ以外は、私には問題ないようです。

于 2011-07-26T04:39:57.900 に答える