上司にSOAP経由でRESTを使用するように説得するにはどうすればよいですか？
システムのAPIを作成する必要があります。 RESTはSOAP（またはXML-RPC））よりも優れたオプションであることを上司にどのように説得しますか？
RESTは...
- 実装と保守が簡単
- 学ぶことはそれほど新しくありません-プレーンな古いHTTP
- 多くの人がそれを選んだYahoo〜Facebook〜Twitter
- コーディングがはるかに速くなります
上司は言うSOAP is ...
- より豊かで表現力豊か
- すべて標準のXML（SOAP、WSDL、UDDI）であるため、使いやすくなります。
- rESTよりも標準化されている
- Googleは多くのSOAPを使用しています
- rESTでカスタムXMLスキーマを作成するよりも、SOAP標準に準拠することが重要です。
両方を使用している人からSOAP and REST広範囲に...
BOSSはSOAPは...
richer and more expressive
誰かが「リッチ」と言ったときはいつでも病気になりたいです。テクノロジーやプラットフォームについてこれ以上の決まり文句のコメントを考えることはできません。基本的には「この製品は素晴らしいと思いますが、しかし、それを裏付ける実際の事実はありません」と言っています。彼が「表現力」で何を意味するのかわからないので、コメントはできません...
すべて標準のXML（SOAP、WSDL、UDDI）であるため、使いやすくなります。
これは明らかに誤りです。 SOAPは、特に複雑なタイプや認証ヘッダーのようなものに取り掛かる場合、気難しい場合があります。これは、クロス言語のコミュニケーションを始めるときに特に当てはまります-取得PHP = .NETを適切に使用して通信するSOAP複雑なタイプと認証を使用していたサービスは、キーボードスナップホラーの練習であり、今日の冷汗で目が覚めました。= RESTは間違いなく消費が簡単です-URLを指定して完了です！データがあります！必要に応じて、これにはいくつかの欠点がありますが、多くのWebサービスではこれだけで十分です。
rESTよりも標準化されている
スキーマを持つことで「標準化」されています。それでおしまい。それとは別に、あなたはまだ他の誰かのデータで作業する必要があります。これは、どの通信プロトコルであってもピクニックになることはありません。あなたが使う。そしてRESTには標準があります-HTTPと呼ばれます。これはかなりうまく機能します。
Googleは多くのSOAPを使用しています
それらは used を使用してSOAP（まだ一部の製品ではあるかもしれませんが、多くはありません）です。Webサービスの大部分はRESTベースです。 （SOAPサービス を放棄してRESTを支持して）を示したリンクを次に示します。
rESTでカスタムXMLスキーマを作成するよりも、SOAP標準に準拠することが重要です。
これは、実際の技術をあまり理解していない上司からのコメントの1つに聞こえます。 SOAP標準化されたパケットの一部のみが存在します-メッセージヘッダーとボディラッパーです。その間のすべてが独自のXMLです。独自のメッセージを作成する必要があります。メッセージ自体は特定の標準に準拠していませんが、シリアル化されたオブジェクトまたはオブジェクトのグループです。
最後の注記として、SOAP対RESTは具体的な答えがないため大きな話題であり、あなたが話す相手に応じておそらく異なる答えを得るでしょう。実際、私は確かには言えませんあなたの特定のケースではREST [〜＃〜] will [〜＃〜]より良いですが、あなたの上司の議論は弱く、2つの違いについての理解が不足していることを示していると言えます。私は両方のテクノロジーを使用してきました。結論、そして他の多くの技術的決定と同様に、それは組織のニーズに依存します。最善の解決策は、真に、思慮深い研究、つまり、プロジェクトに取り組んでいる人々の間で開かれた議論によってbest解決策を見つけることです、そしてあなたのニーズを正直に見てください。
ここに有益かもしれない既存の議論へのいくつかのリンクがあります。
SOAPまたはREST？他の回答は、技術的な観点からこの点を論じるのに役立つ優れた働きをします。ただし、技術的にはどちらのアプローチでもほとんどのことを実行できるため、KOが発生する可能性は低いと思います。技術的なノックアウトにつながる可能性があるいくつかの例外があります。
- aPIリクエストが外部メッセージングミドルウェアを介してルーティング可能でありながら、受信者が元の送信者を認証および検証できる場合、SOAPが優先されます。
- 既存のアプリケーションの認証およびアクセス制御ロジックを使用する場合、RESTは実質的にNOPにすることができますが、SOAPはそれ自体でミニプロジェクトにすることができます。
あなたが上司としてこれらの例外的な要件のいずれかを持っていない場合、そしてあなたはボスではないので（！）、私はあなたが望むことができる最善は抽選であると思います主観的。
しかし..最善の決定をしたい場合（そして単に議論に勝つだけではない場合）、おそらく上司と一緒に別の方法でこれを確認するためにプッシュすることができます。
あなたは「私たちのシステムにAPIを作成する必要がある」ので、これはあなたのシステムの内部の技術的な詳細だけではなく、「技術的な議論は技術的な人々-別名、仕事をする人々」のためのものだと推測していますtが適用されます。あなたが提供するものすべてに対処しなければならない人々のグループがどこかにあります、そして私はおそらく彼らにそれを使ってそれを愛して欲しいと思いますか？その場合：
APIに必要なものはおそらく、あなたまたは上司が思いつく可能性のあるすべての引数よりも優先されます（少なくともそれは彼らが考えていることです）
例えばBizTalkなどを使用してAPIと統合する場合は、おそらくSOAPです（ドキュメントリテラルとすべて）。しかし、それらがAPIに書き込むコーダーである場合、SOAPは養子縁組の死の核になる可能性がありますが、RESTはヒーローになります。
これらの人々が誰であるかをすでに知っている場合は、APIから何が必要かを尋ねるべきだと思います。それが「新しい市場」である場合は、見つけることができる最高の代表者を探し込むか、少なくとも「代表的な顧客環境」が何であるかを説明し、理解して、意思決定に役立つようにしてください。
言い換えれば、実際の外部顧客、または組織内のその他の顧客、または立ち上げ前に適切な暫定ジョブを実行できるパートナーから、顧客の声が見つかるかどうかを確認することをお勧めします。
（その後、「REST！あえてRube Goldberg SOAP怪物をくれないで」と言われたら、上司に知らないうちに微笑みかけることができます）
これは2段階のプロセスです。
経営陣ではなく技術的な方向性を選択するのは技術チームでなければならないことを上司に納得させます。
RESTを選択しました。またはSOAP。またはPOX。または何でも。
技術的な議論は技術的な人々-別名、仕事をする人々のためのものです。上司がテクノロジーを決定し始めると、社会問題が発生します。上司を説得してパイから手を離し、仕事を任せる必要があります。
私はテストを提案します。同じ非常に単純なサービスを実行する2つのソリューションをコーディングします。 SOAPとREST-ful APIを使用して結果を比較します。今日のツールセットを考えると、それほど大きな違いはないはずです。サービスをかなり簡単に立ち上げることができます。
次にAPIを変更します。 REST APIを変更する開発者は、彼らが理解している概念的なプロトコルを扱っているため、簡単に変更を加えることができるのは私の経験です。SOAP APIは何かを達成するためにツールに依存します。手動でそれを実行できますが、生成されたコード/マークアップを確認すると、（明らかな理由により）ほとんどの人が実行しません。
さらに良いことは、上司にSOAP実装を実行させることです。
システムが使用されているさまざまな環境を見て、これらの環境が主に落ち着いた方法でシステム間通信を行っている場合は、システムがそのようなインターフェースも提供しているはずです。 （つまり、顧客がそれを使用する場合は、システムも使用する必要があるということです。）
永続的なボスとコーダーの議論に入る代わりに、いくつかの特定のケースを取り上げて、モデルの適合性を評価しましょう。 REST愛好家は論理的かつ事実に基づく議論で反論することが最も歓迎されます-
目的：サービスのリモート処理/ファイアウォールの制限の打破/ HTTPなどのプロトコルとのバインド
オプション：SOAP/REST（RMIなどのプロトコルをそれがコンテキスト外のものとして破棄する）
使用例1：最適化されたバインディング（JMS/RMI）が必要な理由は、a）トランザクションコンテキストの伝播b）大きなペイロード交換c）厳しいQoSここでは、SOAPを選択します。誰かが複雑なタイプとの相互運用性の懸念について言及しているのを見ました-WS-I基本プロファイルのコンプライアンスで問題を解決できないと思う理由を説明してください（例を挙げてください）。
ユースケース2：信頼された仲介者（アクティブまたはパッシブ）のフェデレーション環境でID（アサーション）伝播が必要です。これはB2Bの使用例です。 RESTエンドポイントを使用してポリシーをアタッチする方法が定義されていないと思います。したがって、SOAPベースのサービスが明らかな選択肢になります
ユースケース3：PaaSの管理APIが必要です。 JMX MBeanはサービスとして公開されます。これは一種のポイントツーポイントの性質です。帯域幅は制約です。ガバナンスは問題ではありません。ブラウザベースのクライアントはそれをより使いやすくします。この場合、HTTPSで十分です。メッセージレベルのセキュリティについて心配する必要はありません。 RESTを選択します。この特定のケースでは、SOAPの複雑さと複雑さは必要ありません。
使用例4：信頼できるメッセージサポートが必要です。 WS-RMはこれを解決できます。 SOAPはここで明らかなモデルです。SOAP engine/app serverはOOTB WS-RM構成をサポートしているためです。
使用例5：TXコンテキストで複数のエンドポイントを呼び出す必要があります。トランスポートプロトコルで使用できるオプションはHTTPのみです。 RESTはWS-ATをサポートしているとは思わないので、SOAPを使用します
使用例6：非同期エンドポイントが必要です。要求しているスレッドを不必要に保持したくない。 SOAPが選択されます。
使用例7：データが最小限の変換またはまったく変換なしでUIに到達するため、XMLから型への変換の不要なオーバーヘッドを排除したいと思います。 REST JSONを使用するのが私の選択です。
一般的に、DATA/RESOURCEを考えている場合、REST操作/メソッドを考えている場合（sync/async .. state..message level security..scalability）I SOAPを使用する傾向がある
ガバナンスとSOAここでの角度を持ち込まないようにします。開発者専用のフォーラムでは、「一体」のように聞こえたくないでしょう。
上記の問題を修正してください。
REST上げられていない重要な利点の1つは、キャッシュ可能で簡単にスケーラブルなことです。SOAPはPOSTであるためキャッシュできませんリクエスト。