5

人々はまだSOAPサービスを書いていますか、それともアーキテクチャの保存期間を過ぎたテクノロジーですか？人々はバイナリ形式に戻っていますか？

4

7 に答える 7

6

SOAPの代替は、バイナリ形式ではありません。

WS- *の複雑さを残して、RESTとJSONを優先したいという要望が急増していると思います。これは、WS- *の方がはるかに使いやすく、フレームワークを正常に使用する必要がないためです。WS- *が表面上解決しようとしている問題は、ほとんどのユーザーにとって問題ではありませんが、とにかく複雑さの代償を払わなければなりません。

于 2008-09-01T21:30:45.570 に答える
4

私はまだWS-*ベースのサービスを書いています。やや意外なことに、能力の低い開発者と相互運用しようとしたときに、問題が少なくなりました。これは、WSDLファイルを送信すると、内部で何が起こっているのかを幸いにも気づかずに、ツールを介してファイルをクランクし、呼び出すことができるAPIを取得する方法を知っているためです。お客様にRESTに対応したサービスを提供するために、私はHTTPとXMLについて話し始める必要がありますが、彼らは実際には理解しておらず、思っているほど理解していません。それから私は頭痛の種になり始めます。

言い換えれば、RESTで成功するには、サービスプロバイダーとコンシューマーの両方が自分たちが何をしているのかを知る必要があります（そして、物事をシンプルに保ち、WS- *以外の優れたソリューションを考え出すことができます）。WS- *テクノロジーを使用すると、片方の当事者だけが手がかりを持っていても成功する可能性があります。

ただし、現在のWS標準よりもはるかに複雑でないREST指向の標準が最終的に出現し、それが発生すると、同等のツールも利用できるようになると思います。

于 2008-09-01T21:49:11.453 に答える
3

そう思います。RESTfulソリューションは、大多数のユースケースでますます賢明になっています。SOAPやその他のRPCテクノロジーの複雑さは、もはや努力する価値がありません。

于 2008-09-01T22:07:33.907 に答える
2

私はSOAPレガシーをまったく考慮しません。RESTとSOAPは、実際にはCOM/CORBAとHTTPPOST/ GETなどの議論の続きにすぎません。SOAPは、CとC（契約、プロバイダー、コンシューマーなど）で定義された同じ原則の更新バージョンにすぎません。 。他の2つが失敗した場合（そしてSOAPはより優れたマーケティングチームを持っている可能性があります）、SOAPは（少なくとも部分的に）成功した​​ように見えます。前任者。そうは言っても、COM/CORBAと同じ欠点があります...本当に複雑になる可能性があります。

現在、RESTはスタイルに戻ってきたばかりだと思います。それは新しいことではありません、人々はそれをもう一度見ているだけです。ウェブを見てください。それはRESTであり、何年も前から存在しています。今から5年後、人々は振り返って、それがレガシーであり、変更する必要があることについて同じことを言うでしょう。それはソフトウェア開発の性質です。すべてが循環します。

どちらが優れているかについての議論は、タブ対スペースの議論と同じようになります。さまざまな側の人々が、どちらかが優れていると誓うでしょう。本当に結局、彼らは両方とも同じ目標を達成します。確かに、状況によっては一方が他方よりも優れたソリューションになりますが、最終的にはどちらも100％優れたソリューションにはなりません。

于 2008-09-01T22:05:42.193 に答える
2

私たちは SOAP を使用していましたが、両方のメッセージング エンドポイント (サーバーに接続する Web 上のシック クライアント) を制御しているため、XML の「リンガ フランカ」には何のメリットもないと判断しました。代わりに、Google プロトコル バッファを介したバイナリ シリアライゼーションを実験しています。これまでに学んだすべてのことと同様です。やや CORBA 風ですが、CORBA のように不機嫌になることはありません。RPC レイヤーに最適なものはまだ見つかっていませんが、ペイロードがプロトコル バッファーになることは間違いありません。

私が言おうとしているのは、会話の両側を制御すれば、XML 税を回避することで効率が大幅に向上するということです。

于 2008-09-23T18:56:28.973 に答える
1

問題が何であるか、言い換えれば、コンテキストが何であるかを考慮せずに、最良のテクノロジーソリューションが何であるかを定義することは不可能です。RESTとSOAPの両方にその場所があります。トラフィックの多いサイトとRESTに慣れている開発オーディエンスがいる場合、主にメッセージサイズが非常に肥大化するため、SOAPは不適切な選択になります。適度な開発予算のある小規模なサイトの場合、WSDLからの自動プロキシ生成により、SOAPが優れた選択肢になります。公平に比較​​するために、REST会話の実装には開発時間がかかるため、費用がかかることに注意してください。これは上司にとって非常に重要な事実です。

SOAPがより複雑なプロトコルであることは事実ですが、私の経験では、これは保守性の問題にはなりません。これは、メッセージがHTTPに乗っており、RESTメッセージと同じように簡単にデバッグでき、主要なプラットフォームで利用可能なSOAPスタックが非常に安定しているためです。

もちろん、SOAPの複雑さは、要件にフェデレーションメッセージセキュリティなどの高度なアイテムが含まれている場合に有利です。一方、この種の要件は、私の経験ではそれほど頻繁には見られません。WS標準委員会はいくつかのYAGNI問題に対して脆弱であった可能性があります。Webサービスの通信が一般的になったことで、当初想定されていたよりも単純なものになりました。

于 2011-07-07T17:28:41.137 に答える
1

はい、まだそうしている人もいます (そして今は 2011 年です!)。主な理由は、MS WCF が SOAP バインディングを自動的に生成するためだと思います。ホラー。

于 2011-07-07T17:12:26.947 に答える