単一のエントリポイントを備えたSOAの休憩

Question

すべてのクライアントリクエスト用の単一のゲートウェイを備えたサービス指向アーキテクチャがあります。ゲートウェイは整頓されており、すべての「内部」サービスを隠し、ディスパッチャーと自家製のロードバランサーとして機能するため、私はこれが好きです。

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

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

私のアーキテクチャが安らかではないので、私は悲しいべきですか？私は休憩のようにhttpをレバレッジしていませんか？批評してください。

Answer 1

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

• UIをデータストレージから分離するクライアントサーバーの相互作用
• ステートレスサーバー、信頼性とスケーラビリティの向上
• クライアントキャッシュ、いくつかのネットワークトラフィックの削減
• 均一なインターフェイス、彼らが提供するサービスからの実装を切り離す
• 各コンポーネントがそのすぐ下またはそのすぐ上のコンポーネントのみに関係しているレイヤードシステム
• リソースの観点から考える表現の方向
• hateoas、アプリケーションは本質的にリンクをナビゲートします
• 少数の動詞を備えた制約付きインターフェイス（例：GET、PUT、POST、削除、およびその他約3つだけ）

SOAPまたは別のRPCソリューションを使用すると、休息の代わりに、理論的には、これらの特性のすべてではなくいくつかをあきらめます。あなたはクライアントのケキアビリティをあきらめている可能性があり、あなたは手続き的に考えている可能性があり、おそらくあなたはRestafarianがティーに活用するすべての安全性と等しい条件を使用することはできません。

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

独自のAPIを使用して、200と404を返して、すべてを取得することを行う場合は、APIは概念的にシンプルであり、おそらくあなたのためにうまくいくでしょう。ただし、さまざまなメディアタイプが必要であり、頻繁に追加され、削除され、作成され、更新されるコレクションを含む永続的なストレージ要件がある場合、最新のRestful APIデザインを学習すると、少なくとも新しい考え方が開かれます。

結論は、他のみんながそれをしているので、悲しみを感じたり、休息に行かなければならないと感じたりすることはありません。しかし、利点は本物であり、休息は単なる誇大広告ではありません。

Answer 2

いいえ。基本的に、XMLの代わりにJSONを使用して、自宅の醸造石鹸スタイルRPCがあります。

SOAPスタックを使用するのではなくJSONで再発明する価値があるかどうかを尋ねるかもしれませんが、JavaScriptと話している場合は、石鹸よりも使用する方が簡単かもしれません。 。

それ以外は、私には大丈夫だと思われます。