RESTfulサービス-同等のWSDL

私はRESTとSOAPについて読んでいて、SOAPプロトコルを使用するよりもRESTを実装する方が有利な場合がある理由を理解しています。ただし、RESTの世界に同等の「WSDL」がない理由はまだわかりません。WSDLが「不要」である、またはRESTの世界では冗長であるという投稿を見てきましたが、その理由はわかりません。手動でコーディングするのではなく、プログラムで定義にバインドしてプロキシクラスを作成することが常に便利ではないでしょうか。RESTにWSDLがない理由、またはWSDLが不要な理由を探すだけで、哲学的な議論に入るつもりはありません。ありがとう。

の Webアプリケーション記述言語（WADL）は、基本的にRESTfulなサービスのためのWSDLと同じですが、このようなものは全く必要とされているかどうかを継続的な論争が行われています。

Joe Gregorioは、そのトピックについて、読む価値のある素晴らしい記事を書いています。

WSDLはサービスのエンドポイントを記述します。RESTクライアントをサーバーエンドポイントに結合しないでください（URLを事前に認識してはなりません）。RESTクライアントは、クライアントとサーバーの間で転送されるメディアタイプに結合されます。

クライアントでクラスを自動生成して、返されたメディアタイプをラップするのは理にかなっています。ただし、サービスの相互作用に関するプロキシクラスの作成を開始するとすぐに、HTTPの相互作用が不明瞭になり始め、RPCモデルに向かって縮退するリスクがあります。

RSDLは、ハイパーメディアのように休息することを目的としています。つまり、RSDLは、WSDLやWADLのようなサービス記述子よりも多くの情報を持っています。たとえば、ハイパーテキストやハイパーリンクなどのナビゲーションに関する情報があります。

たとえば、現在のリソースを指定すると、関連する別のリソースへのosリンクが設定されます。

ただし、この形式をサポートするRestクライアントや、自動生成する機能を備えたRestサーバーソリューションは見つかりませんでした。

それについて結論を出すには長い道のりがあると思います。HTMLの長い話とW3C対ブラウザの笑をご覧ください。

HypermediaのようなRestの詳細については、http：//en.wikipedia.org/wiki/HATEOASを参照してください。

注：ロイフィールディングは、過敏症アプローチなしのRest Apisにおけるこれらの傾向を批判しています：http ://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

私の結論：さて、WADLは、Camel CXFのようなRESTおよび統合フレームワークがすでにWADL（生成および消費）をサポートしていることより一般的です。これは、WSDLに似ているため、この移行プロセス（SOAPからREST）で最も理解しやすいためです。

次の章を見てみましょう;）

手動でコーディングするのではなく、プログラムで定義にバインドしてプロキシクラスを作成することが常に便利ではないでしょうか。

心から同意する、これが私がSwagger.ioを使用する理由です

Swaggerは、RESTful APIの設計、構築、文書化、および利用を支援するツールの大規模なエコシステムに支えられた強力なオープンソースフレームワークです。

つまり、基本的にはSwaggerを使用してモデルやエンドポイントなどを記述し、次にswagger-codegenなどの他のツールを使用します手動でコーディングする代わりに、てプロキシクラスを生成します。

参照：RAML

WSDLに相当するRSDL（restful service description language）があります。以下のURLは、http：//en.wikipedia.org/wiki/HATEOAS およびhttp://en.wikipedia.org/wiki/RSDLの実践について説明しています。問題は、wsdlからjava、またはその逆のコードを生成するためのツールがたくさんあることです。しかし、RSDLからコードを生成するツールは見つかりませんでした。

WSDLは拡張可能であり、通信に使用されるメッセージフォーマットやネットワークプロトコルに関係なく、エンドポイントとそのメッセージの記述を許可します

ただし、RESTは、HTTP動詞とURIを使用してネットワークプロトコルを使用し、オブジェクトの状態を表します。

WSDLはこの場所で通知します。このメッセージを送信すると、このアクションが実行され、結果としてこのフォーマットが返されます。

RESTでは、新しいプロファイルを作成したい場合はPOST、URLにプロファイルを記述するJSONボディまたはhttpサーバー変数を含む動詞を使用します/profile

POSTステータスコード201 CREATEDとヘッダーを使用して、サーバー側で生成されたIDを返す必要がありますLocation: *new_profile_id*（例：12345）

次に/profile/12345、HTTP動詞を使用して状態を変更する更新を実行できますPOST。たとえば、メールアドレスや電話番号を変更できます。明らかにリモートオブジェクトの状態を変更します。

GET の現在のステータスを返します /profile/12345

PUT 通常、クライアント側で生成されたIDに使用されます

DELETE、明らか

HEAD、本文を返さずにステータスを取得します。

RESTを使用すると、適切に設計されたAPIを介して自己文書化され、使いやすくなります。

これは RESTに関するすばらしい記事です。それも本当に理解するのに役立ちます。

WSDL 2.0仕様では、REST Webサービスのサポートも追加されています。両方のシナリオのベスト。問題は、WSDL 2.0がほとんどのツールでまだ広くサポートされていないことです。WSDL 2.0はW3Cを推奨し、WSDL1.1はW3Cを推奨していませんが、ツールや開発者によって広くサポートされています。参照：http : //www.ibm.com/developerworks/library/ws-restwsdl/

Webアプリケーション記述言語（WADL）は、RESTful Webサービスを記述するために使用されるXMLボキャブラリーです。

WSDLと同様に、汎用クライアントはWADLファイルをロードして、対応するWebサービスのすべての機能にアクセスできるようにすぐに備えることができます。

RESTfulサービスのインターフェースは単純であるため、WSDLはRPCスタイルのSOAPサービスに対するものであるので、WADLはこれらのサービスにとってそれほど必要ではありません。