REST対SOAP。 パート2。プラットフォーム通信を整理するのはどのように簡単で効率的ですか？

記事の最初の部分を書いた後、私の食欲は高まり、今度は実用的な部分に焦点を当てて勉強を続けたいと思いました。 アプリケーションとプラットフォーム間の相互作用が必要なため、私たちの大騒ぎはすべて燃え上がっています。そのため、この記事では主にこれに専念します。

目次：

REST対SOAP。 パート1。違いを感じてください。

REST対SOAP。 パート2。プラットフォーム通信を整理するのはどのように簡単で効率的ですか？

なんでこんなこと？

アプリケーション間、特に異なるプラットフォームで作成されたアプリケーション間の相互作用が必要なのはなぜですか？ もちろん、愚かな質問です。 プログラミングの世界では、完全に独立したいくつかの場所、およびいくつかの場所では敵対的なプラットフォームが存在し、並行して開発されています。 さらに、膨大な量のソフトウェアがすでに作成され、正常に動作しているため、新しいプラットフォームごとにソフトウェアを書き換えることはありません。 銀行を例にとってみましょう。 社内のすべての銀行プログラマーは常にJAVAで記述されているため、銀行には5年間正常に機能するサービスがあります。最近、AndroidのほぼすべてのバージョンのOSで安定して動作する美しいモバイルアプリケーションが登場しました。ハリコフ大学では、依然として高度なウェブ技術（jk）の例として示されています。 そして今、Windows用のデスクトップバンキングアプリケーションを開発するタスクがあります。 銀行はアウトソーシング会社にWPFアプリケーションを注文しました。 通信プラットフォームを整理する方法は？

ちょっとした歴史

例から脱線し、歴史に目を向けましょう。 サイトを書くためにHTTPプロトコルを知る必要がない.Netの時代にプログラマーの仲間に加わり、WinAPIについて聞いたこともなく完全に機能するデスクトップアプリケーションを書くことさえできるので、私がこれを行うのはおそらく同僚の多くよりも難しいでしょう。 。 しかし、私はそのような遠足をしようとします。 メイントピックから離れないように、恐竜の時代（1998年にXMLの出現により恐竜が絶滅したと想定しています）を特に考慮しません。 2つのアプリケーション間で確立された接続があり、1つがバイトを送信し、もう1つがバイトを受信するとします。 次は？ アプリケーションは、たとえば、「1」が「すべての顧客のリストを送信する」、「2 | 36782」-「クライアント36782のトランザクションのリストを送信する」ことを意味することに同意する必要があります。 おそらく中生代の全盛期にこのようなことが起こったのでしょう。 そのため、開発者はアプリケーションのやり取りごとに新しいバイクを開発する必要がありました。 インターネットの開発（90年代半ば）で、アプリケーションは、合意されたURLで合意された形式で情報を提供することで情報を交換することができました（後に「REST」と呼ばれます）。 XML-RPCが出現する前のプロトコルとアプリケーションの通信方法 -コメントを懐かしく思う人がいるかもしれないという理由だけで、私は書きません。

RPC

RPCは「リモートプロシージャコール」であり、非常に古い概念であり、古代、中、現代のプロトコルを組み合わせて、別のアプリケーションでメソッドを呼び出すことができます。 XML-RPCは、XMLの登場直後の1998年に登場したプロトコルです。 当初はMicrosoftによってサポートされていましたが、すぐにMicrosoftは完全にSOAPに切り替えたため、.Net Frameworkでこのプロトコルをサポートするクラスは見つかりません。 それにもかかわらず、XML-RPCはいまだにさまざまな言語（特にPHP）に住んでいますが、明らかにそのシンプルさから開発者の愛を獲得しています。 長い間履歴書で私が書いたことをあなたが最終的に理解したときの面白い感じ。 これはXML-RPCと私の学生の履歴書です。 :)

SOAP

SOAPは、Microsoftの努力により1998年にも登場しました。 これは、ソフトウェアの世界における革命として発表されました。 これは、すべてがマイクロソフトの計画に従っていたということではなく、プロトコルの複雑さと重さのために非常に多くの批判がありました。 同時に、SOAPを真の突破口と見なす人もいました。 プロトコル自体は進化し続け、2003年にW3CがSOAP 1.2を勧告として承認するまで、新しい仕様と新しい仕様が多数作成されました。 SOAPファミリーは印象的であることが判明しました。ここに彼らの家族写真があります：



（写真では-WS-Addressing、WS-Enumeration、WS-Eventing、WS-Transfer、WS-Trust、WS-Federation、Web Single Sign-On ...そして、右側の2番目のものは覚えていません）



10年以上にわたって、SOAPをめぐる議論は収まりませんでしたが 、その低速のために、輻輳が依然として厳しく批判されています。 しかし、プロトコルは死ぬことはなく、むしろ反対に、世界もそれを捕捉しませんでした。 プロトコルに対する批判はほぼ真実です。HTTP機能は使用されず、 メッセージの長さはRESTよりも長くなります。これらのWS-FederationおよびWS-AtomicTransactionのすべては、多くの場合使用されません。



しかし、私は他のことに焦点を当てたいと思います。SOAPプロトコルファミリを使用して、どれだけ迅速に分散アプリケーションを開発できるのでしょうか。 これはマイクロソフトが私たちに約束した革命ではありませんか？ 私の意見では、それは彼女です。 コード内の属性を他にどこに配置し、サービスの[公開]ボタンをクリックし、クライアントの[プロキシを生成]ボタンをクリックして、同じプロジェクト内にあるかのようにコードを呼び出しますか？ したがって、最前線は、そのような物語がどの言語とプログラミング環境で可能かという問題です。 このデータをテーブルに削減しようとします。

しかし、RESTについてはどうでしょうか。

アドレスからSOAPへのあらゆるお世辞の言葉にもかかわらず、私はRESTアプローチが不要であると言うつもりは決してありません。 RESTという用語は2000年に登場しました。 SOAPの最初のバージョンからわずか2年後。 アプローチ自体ははるかに早く現れ、2000年に単純に実現、文書化され、名前は長い「私はあなたにそのような情報を与えます」から理解できない「REST」に変わりました。 名前の由来とRESTの原則については、 この記事の最初の部分で詳しく説明しました。 ここでは、RESTが最適に使用される場所とその理由に焦点を当てます。

1. javascriptから使用されるサービス内。 ここで言うことはありませんが、javascriptはjsonでうまく機能するため、これを提供する必要があります。
2. クライアントプロキシを生成する方法がない言語から使用されるサービス。 これは、たとえばObjective-Cです。 SOAPエンベロープを手動で解析する必要はありません。これは必要ありません。
3. 非常に高いパフォーマンス要件がある場合。 これらは通常、Twitter APIやGoogle APIなどの非常に頻繁に使用されるAPIです。

そして、SOAPを使用する場合：

1. SOAPを使用した開発を加速するツールが存在するプラットフォーム間で相互作用が発生した場合。 たとえば、.NetおよびFlexから使用されるSOAPサービスをJAVAで記述するのが適切です。
2. すべてのSOAPチートの恩恵を受けることができる場合。 私は誰かがこれを行うことをどうにかして信頼できる情報を持っていません。 明確な例が思いつきません。

したがって、 サポートされている場合はSOAPを使用する必要があり、そうでない場合はRESTを使用する必要があります 。 これにより、コードを詳細に解析してそこに新しいフィールドを追加する代わりに、「サービス参照の更新」ボタンをクリックするだけで、Webサービスクライアントの開発と変更にかかる時間が大幅に短縮されます。



.NetでのRESTサービスとSOAPサービスの開発速度は同じです。 WCFでは、一般的にSOAPサービスをRESTfulに、またはその逆の単純で時間のかかる詐欺によってその逆に変えることができます。したがって、開発速度を加速するということは、サーバー部分と同時に、さらに後で完全に開発できるクライアント部分を意味します別の会社。 サービスが大規模で複雑なデータ構造を受け入れて返す場合、SOAPを使用する利点は大きくなります 。

SOAPの日は番号付けされていますか？

RESTとSOAPはどちらも正常に使用されるようになりましたが、批評家が書いているように、SOAPが実際に消滅する可能性があります。 私の意見では、これは、RESTfulサービスのWSDLまたは同様のプロトコルが使用され始め、クライアントプロキシの生成が可能になる場合に可能です。 そのようなクリープがあり、プロトコルはWADLと呼ばれていましたが、現時点ではそのようなものは存在しません。 もちろん、そのようなシナリオでは、ITの世界の少なくとも1人の主要なプレーヤーの欲求とまともな努力が必要になりますが、私はそのようなオプションを除外しません。 そして、ネットワークアーキテクチャのシンプルさと利点、およびクライアントプロキシを使用したアプリケーションインタラクションの自動化という2つの世界のベストを獲得します。

例

記事の最初からこの例を忘れていましたか？ 彼は人生から連れ去られました。 JAVAで記述された既存のサービスからデータを受信するWPFアプリケーションが開発されていることを思い出させてください。 この記事に従ってすべてが美しく見えるように、彼はどのフォーマットでデータを提供できますか？ そう、SOAPで。 そして彼はjsonを与えます。 「RESTの意味でこれはどのようなjsonなのか」という考えを誰も持っていないことを願っています。 もちろんREST ！ RESTは、単純なXML、json、または「Vasyaが求めた」形式であっても、他の要求された形式でデータを返すことができます。ただし、この形式を推奨W3C標準の1つにするか、これにより：



Content-Type: application/as-Vasya-asked; charset=utf-8







私たちはビジネスから気を取られています。 さて、このサービスはjsonでデータを返しますが、何が私たちを脅かすのでしょうか？ ただし、ここに問題があります。クライアントのプロキシを生成することはできません。リクエストとパースの回答を手動で送信する必要があります。 HttpWebRequestまたはアドオンを使用する必要があります。 そして、SOAPがあります-顧客のお金が節約されます。

おわりに

言語やプラットフォームに関係なく、アプリケーションの相互作用の全体像をかなり概説できたと思います。 説明した3つのアプローチ（REST、XML-RPC、SOAP）がすべて可能なオプションではないことを付け加えました。 たとえば、ソーシャルネットワーク（Flexで記述された）のおもちゃは、ソケットを介してC＃で記述されたサーバー側への直接接続を確立することがよくあります。 このため、新しいアプリケーションごとにモペットを発明する必要性とともに、速度の向上が得られます。 どこかですでに...

重要なものを見逃した可能性があります。特に.Netに関係がない場合は、それについて知ってうれしいです。



PS昨日私のカルマを増やしてくれたint03e 、 SSSurkvと1nd1goに感謝します。