SOAPサービスの代わりにRESTful Webサービスを提供するようにクライアントを説得しますか？
バックグラウンド：
私はクライアント用のカスタムWordPressプラグインを開発し、それを the WordPressプラグインリポジトリ を介して配布しています。私のWordPressプラグインに内部開発チームによって開発されたSOAP Webサービスを使用してほしいクライアントにますます実行しています。これらのSOAP Webサービスの1つは、ASP.NETを使用して開発されました。）
私の経験から、特にWordPressプラグイン開発の領域では、RESTful Webサービスとのやり取りはほとんどの場合取るに足らないことであり、機能するだけです。実際にSOAP WebサービスをWordPressプラグインを介して実際に消費することについての私の確かな第三者の知識から、特にほとんど技術者でないWordPressユーザーに広く配布されているプラグイン、埋め込みSOAPクライアントは、SOAP Webサービス呼び出しが失敗する原因となる可能性があるため、危険にさらされています。ローカルSOAPスタックの誤り、ローカルSOAPスタックの欠落、不正なサービス応答など.
私が見つけているのは、（見込み）クライアント内で意思決定を行うビジネスパーソンの多くが、RESTful WebサービスとSOAPの具体的な違いについてほとんどまたはまったく知識を持っていないということです。ベースのWebサービス。これらの人々にとって、WebサービスはWebサービスです。それは6の1つ、他の1/2ダースです。彼らは「すべての大騒ぎとは何ですか？」
さらに、これらのクライアントのASP.NET開発者、Visual Studioツールセットに没頭している開発者は、SOAPを簡単な方法と見なすために、Microsoftの優れた開発者ツールマーケティングによって条件付けられています。 Visual Studioを追加するだけで、SOAP Webサービスが魔法のように機能します。そして、少なくとも、他のスタックを使用してWebサービスにアクセスしようとするまで、および/またはVisual Studioを使用していないか、Webサービスを採用していない人を獲得しようとするまではそうです。その後、画像は非常に異なります。
これらの開発者が私の主張を聞いたとき、代わりにRESTful Webサービスを実装します。プッシュバックを受け取った場合、2つの応答のうちの1つを受け取ります。彼らが言うには：
「私がすでに使用するSOAP Webサービスを作成したのに、RESTful Webサービスを作成するためのすべての努力に行くのはなぜですか？あなたは私と私のためにより多くの作業を作成しているだけです。他にやることがあります。」
"RESTful Webサービスにはメリットはありません。オブジェクトを作成して、オブジェクトのようにプログラムできるので、SOAPは実際にははるかに優れています。プラスSOAPはエンタープライズ開発者が使用しており、私たちはエンタープライズ開発ショップです。RESTは真剣に使用するためのものではありません。 "
余談ですが、これらの応答が得られる理由の1つは、ASP.NET開発者がREST にほとんどまたはまったく触れていないことが多いためだと思います（この記事は実際には余計なものではありません）ほとんどのASP.NET開発者ですか？） HTTP GET- only RESTful Webサービスを作成するために必要なすべてのコードがすでに実装されている場合、どれだけの作業が必要かを実際には知らないと思いますSOAP Webサービス。
これは、Microsoftのアプローチが開発者にツールを提供することであり、開発者が詳細を学ぶ必要を感じないために発生すると思います。 Visual Studioは開発者にとって非常に多くのことを管理すると主張しているので、なぜ開発者がVisual Studioが処理すると主張していることを何でも学ばなければならないのですか？私がMicrosoftプラットフォームのWebサイトをコーディングするのに使用していたとき、それは私が思っていたことだと知っています。 PHPに移動するまでは、HTTPヘッダーとは何かを理解し、301と302のHTTPステータスコードの違いに気づきました。最も重要なのは、これらの概念はどちらも簡単に理解できることです。 Web上に堅牢で効果的なサイトを作成したいかどうかを理解し、理解することが極めて重要です。
私の質問：
私が求めているのは、これらの応答にどのように対抗し、見込み顧客にRESTful Webサービスの作成を検討させるのですか？どのようにしてクライアントにRESTful Webサービスを使用することで得られる多くのメリットまた、大きなサポートコストが発生する可能性のあるWordPressプラグインをリリースすることの大きな潜在的なマイナス面をどのようにして彼らに理解させることができますか？
注意：
SOAPプラグイン内からWordPress Webサービスを呼び出すよりもRESTful Webサービスを呼び出す方が望ましいという私の前提に同意しない場合は、同意する人からの助けを求めていることを理解してください私の前提であり、理想的にはその前提について議論するつもりはありません。
ただし、論争の必要性を感じた場合は、敬意を持ってそうしてください。私たちにはそれぞれ私たち自身の意見に対する権利があり、あなたが私にあなたの意見に同意することはできないかもしれないことを認識してください。もちろん、どちらでもかまいません。
だから私はあなたの立場に同意する傾向がありますが、私はまだバランスのためにいくつかのアイデアを捨てます。最初の問題：
「私が使用するSOAP Webサービスをすでに作成しているのに、RESTful Webサービスを作成するためのすべての努力に行くのはなぜですか？他にやることがあります。」
問題は、彼らがすでに仕事をしているということです。おそらく、あなたの説明に基づいて、これらのWebサービスはWCFサービスです。 MicrosoftはSOAPベースのWebサービスを作成する手間を省きました。そのため、開発/保守の観点からは、WCFスタックを使用するだけでクライアントの観点から理にかなっています。彼らが自分でSOAPスタックをローリングするという問題を経験したとしたら、そんなに売れることはないでしょう。
私が見るように、問題はWordpress（PHPテクノロジー）がSOAPを処理するために十分に装備されていないことです。 SOAPは、HTTPプロトコルの「標準」非標準適応です。つまり、通常のクライアントの一部としての一般的な要求とHTTPヘッダー情報の代わりに、XML本体もあります。そのXMLは通常、オブジェクトにマップされ、独自のヘッダー情報を持っています。要するに、PHPがそのまま使用できるように設計されているものではありません。 PHP：SOAP を使用していますか？うまくいけば、SOAPの使用が簡単になります。
ただし、実用的な戦略については後で詳しく説明します。
"RESTful Webサービスにはメリットはありません。オブジェクトを作成して、オブジェクトのようにプログラムできるので、SOAPは実際にははるかに優れています。プラスSOAPはエンタープライズ開発者によって使用されており、私たちはエンタープライズ開発ショップです。RESTは真剣に使用するためのものではありません。 "
これは実際にははるかに扱いやすいです。つまり、私が見たほとんどのWebサービスには、非常に単純な要求モデルがあります。渡す必要があるのは、IDと認証トークンだけです。これは、RESTful Webサービスが繁栄するささいなタイプの対話です。オブジェクトのXMLまたはJSONバインド表現を非常に簡単に返すことができます。実際、MSスタックには、それらのbothのバインディングロジックがあります。クライアントが複雑な階層データをサーバーに送信する必要はほとんどありません。
あなたとあなたを幸せにする実用的な方法
ばかげているように聞こえるかもしれませんが、Webサービスラッパーを検討しましたか？ REST呼び出しをWordpressを幸せに保つためにSOAPベースの呼び出しに変換するものは、クライアントのWCFサービスを幸せにしますか？それはそれを扱う最も平和的な方法かもしれません。 ASP.NET MVCを使用してRESTful Webサービスを実行した後、必要な場所にMicrosoftスタックに物事を保持し、PHPスタックへの変換を適切な方法で実行するのは簡単です。
ここにあなたのための考えがあります：なぜあなたはクライアントに彼らが求めるものを与えないのですか？結局のところ、彼らはあなたのクライアントであり、彼らの最初のポイントは非常に有効なものです。 SOAPサービスについてのあなたの中古の評価のために、なぜ彼らは余分な仕事をするべきですか？
これによりワークロードが増加すると本当に確信している場合は、彼らが提供するサービスのタイプが契約に書き込まれていることを確認し、SOAPを指定する場所で入札してください。
マイクロソフトスタックの開発者に対する牛肉を使った言語トロールではなく、正しいことが証明されれば、次に開発者（彼らはおそらくあなたが信頼しているよりもはるかに多くを信頼している）に電話するよりも良い議論をするでしょう。太って、ばかげて、幸せです。」
あなたへの私の答えは、あなたはできないということです。私はあなたのクライアントを知りませんが、あなたの説明から、彼らは彼らの決意において両義的であるかのように聞こえません。彼らはあなたにサービスを提供するように頼んだので、私はあなたにそれを提供するか、次に進むことを勧めます。
補足として、質問の本文の多くは、怠惰なプログラマーを作成したというマイクロソフトに対する非難に関係しています。これはMicrosoftの質問に対するあなたの告発ですか、それともSOAPを使用することを決定したプログラマーに関連していますか？あなたは彼らを怠惰と呼んでいますか、それともソフトウェア会社でポットショットを撮っているだけですか？これは、彼らがあなたの快適ゾーンを彼らの喉の下に押し付けることよりも、彼らが「より良い」技術を使用するようにさせることの政治についてより少ないと私は思う。フリーランスの開発者としての私の提案（ここで私が想定していること）は、クライアントの要件に適応することを学ぶ必要があるということです。代替ソリューションの推奨が適切なのは、具体的なコスト/利益分析を示すことができる場合、またはクライアントが関連するプロセスについて実際の知識を持たず、情報に基づいていない意思決定を行っている場合のみです。
それ以外は、公理に従うのに役立ちます：顧客は常に正しいとは限りませんが、顧客は手形を支払うものです。
注：私はあなたが正しいとは決して言いませんOR間違っています。私のコメントは、クライアントの方法に関してあなたの側で何が曖昧であるかを指摘することを単に意図しています/ provider関係が機能します。ここに関係する人々/ツールに対するあなたの認識を、特にあなたが物事をどのように見るかについて、レビューしてもらうことも試みています。
クライアントがあなたに支払わなければならない価格を説得する
より多くの労力/コストの代償を払わなければならない：クライアントかあなたか。
この問題は価格によって解決できます。soap-serviceの統合は、RESTの統合よりもクライアントにとってコストがかかります。このようにしてクライアントは選択をします。
あなたは、SOAPが嫌いなために結ばれたMicrosoftに対して非常に多くの偏見を持っているようです。 SOAPの初期の歴史は、Microsoftプロジェクトからのものです。しかし、あなたが知っていると思いますが、これは8年近くの間W3Cの推奨事項であり、SOAP仕様は現在W3CのXMLワーキンググループによって維持されています。
実際、最近では、.NET開発者よりもSOAP開発者のJava Webサービスに遭遇することが多くなっています。しかし、Javaと.NETの両方の開発者は、ほとんどすべての主要なプラットフォームでクリーンかつ簡単にサポートされるため、これを好む傾向があります。 PHPでSOAPサービスとのやり取りにこんなに苦労していることに正直に驚いています。実際にPHPの経験はありませんが、このような広範囲のサポートができると本当に思っていました。そして長い標準化されたプロトコル。
これらの開発者が新しい.NETのものを使用していると想定すると、WCFを使用する必要があります。次に、サービスを実行するREST対SOAPは難しいことではありません-バインディングを切り替えるだけで、バインディングが完了します。同じコードベースで簡単にサービスを提供できます。すべての側面。
PHP側からは、SOAPに慣れていない可能性がありますが、SOAP nuSOAPを使用しています。AFAIK、PHP 5+にはSOAPスタックが組み込まれているので、ものを操作するのはそれほど難しくありません。
あなたは間違っている、マイク。クライアントがSOAPサービスを導入している場合、SOAPの憎しみを脇に置いてそれを処理することをお勧めします。怠惰、無能、またはファンではないものを使用するのに苦労している場合は、いつでも割り当てと既に支払われている金額（および契約で規定されている場合は解雇手数料と罰金の可能性があります）をいつでも返すことができます。
あなたの仕事をする代わりに、あなたは彼らがあなたのためにそれをしなければならないことを顧客に伝えています。
私はあなたが遠近法の深刻な問題を抱えているとあなたに言っている他の答えに心から同意しますが、私は両方の点に取り組むための実用的な解決策を持っています：
1）SOAP使用するWebサービスをすでに作成しているのに、RESTful Webサービスを作成するためにすべての労力を費やす必要があるのはなぜですか？やる事。
SOAPサービスがWCFを使用して構築されていると仮定すると、実際にはまったく手間がかかりません。必要なのはwebHttpBindingと2、3の属性、そしてブームが完成したら、それはRESTです。少なくとも、この目的のためにREST）に十分近い概算です。
2）RESTful Webサービスにはメリットはありません。 SOAPは、オブジェクトを作成して、オブジェクトと同じようにプログラムできるため、実際にははるかに優れています。さらに、SOAPは、エンタープライズ開発者によって使用され、エンタープライズ開発ショップ; RESTは、真剣に使用するためのものではありません。
changeingのアーキテクチャはSOAPから休む）のメリットはないかもしれませんが、WCFでは複数の同じサービスのバインディングでは、単にREST（webHttpBinding）およびSOAPサービスを並べて実行できます。これには1つあります。即時かつ非常に明白な利点：実装する方が安上がりすでに[JSON/POX /何でも]をサポートしているため。20分の作業が彼らの契約で1000ドル節約できるなら、私は彼らが利点を目にすることを確認してください。
さまざまなプログラミング言語は、1つのスタイルのWebサービスインターフェイスでよりよく機能する傾向があります。たとえば、私はJavaがSOAPで実際に最近（それのために本当に優れたツールがたくさんあります）の方が幸せです）であり、私の同僚がRubyはRESTでより便利です。さらに、一部の機能はSOAPまたはRESTに強く制限されています。SOAPはHTTPに関連付けられておらず、 RESTは、大きなファイル転送に最適です（これはすべてSOAPメッセージ指向であるのに対し、RESTはより接続指向です。）
とにかくすべての状況でSOAPとRESTの間に明確な勝者がいないことを考えると、なぜあなたにお金を払う人に偏見に対応できますか？それらが動作しているすべての制約を知っているわけではありません。サービスを動作させるすべてのクライアントソフトウェアを知っているわけではありません。代わりに、ソフトウェアをより堅牢にする方法を調査する必要があります識別された構成の問題（パッケージの変更や依存関係の減少など）コードのインストール方法と使用方法に関するドキュメントを改善したり、インストールサポートを販売したりするだけで十分な場合もあります。