WADLを使用する理由は何ですか？

RESTfulを説明するために、すべてのリソースには独自のURIがあると言えます。HTTP GET、POST、PUT、およびDELETEを使用して、これらのリソースを操作できます。すべてのリソースは代表的なものです。私たちのリソースを使用したい人は誰でも、ブラウザまたはRESTクライアントを介して使用できます。

これがRESTfulアーキテクチャの主なアイデアです。このアーキテクチャにより、インターネット上でのサービスが可能になります。では、なぜこのアーキテクチャにWADLが必要なのですか？WADLは、標準のHTTPが提供しないものを提供しますか？なぜWADLが存在する必要があるのですか？

WADLの目的は、 契約です。契約は、ある当事者が別の当事者に電話をかける方法を指定します。

Webアプリケーションを最初から作成する場合、 契約やWADLは必要ありません。

システムを他のシステムと統合し、開発チームと明確にコミュニケーションできる場合、 場合、契約やWADLは必要ありません（電話をかけて明確にすることができるため）。

ただし、複雑なエンタープライズシステムを、複数の異なる企業（または連邦機関）によって維持されている他のいくつかの複雑なエンタープライズシステムと統合する場合は、通信契約をできるだけ厳密に定義する必要があると考えてください。次に、WADLまたはオープン仕様が必要です。ひどく必要です。

企業のバックグラウンドが弱い人は、IT全体を独立して開発された個別のWebアプリケーションのコレクションと見なす傾向があります。しかし、企業の現実は時には厳しいものです。統合する必要のあるアプリケーションを開発している人に電話したり、手紙を書いたりすることさえできない場合があります。メンテナンスされなくなったレガシーアプリケーションと通信する場合があります。実行されるだけで、適切に通信する方法を理解する必要があります。そのような状況では、それはあなたのお尻を節約するので、あなたは契約が必要です。

実際、クライアントの生成は、コントラクト定義のマイナーな機能です。ただのおもちゃです。契約は、統合ルールを明確に伝達するために悪いコミュニケーターを強制します。これが、WADLやオープン仕様などを使用する主な理由です。

WADLを使用するということは、やり取りするデータ/ドキュメントを実際に定義するのに十分な優雅さがあるかもしれないことを意味します。いくつかのXMLフラグメントを渡すとすると、それらは実際には定義されたスキーマの一部である可能性があります。

DLを使用してコードを生成するかどうかは、私にとってそれほど重要ではありません。私の主観的な意見では、重要なのは、ビジネスパートナー間のインターフェースについて正式な合意を結ぶことが重要であるということです。渡されたものが明らかな場合でも、誰かが前のインターフェイスを変更した場合、後で誰が何を修正する必要があるかを特定するのに役立ちます。

データ形式は、動詞名と同じくらいインターフェースの一部です。

WADLは、コードジェネレーターを使用してWSDLに基づいてクライアント側のコードを作成するのが一般的であるSOAPの世界から来た人々にアピールします。このメカニズムは、サーバーエンドポイントに結合されたクライアントコードを作成するため、RESTでは有用ではないと思います。

メディアタイプを適切に定義し、それらのメディアタイプ内でハイパーメディアを使用する場合は、WADLを使用する必要はないと思います。使用可能なエンドポイントの説明は、メディアタイプ定義自体に含まれています。そして、あなたが今あなた自身に言っているが、application / xmlが利用可能なハイパーリンクについての情報を含んでいないなら、私はビンゴと言います。そのため、application / xmlとapplication / jsonはRESTに適したメディアタイプではないと思います。XMLやJSONを使用しないと言っているのではなく、一般的なメディアタイプ名を使用しないでください。

WADLのもう1つの魅力は、RESTサービスを文書化することです。残念ながら、WADLがサーバー側のエンドポイントを文書化しようとするため、開発者は間違った道をたどります。RESTサービスの文書化は、主にメディアタイプに焦点を当てる必要があります。クライアント開発者は、ルートURL以外のURLを知らなくてもRESTクライアントを作成できる必要があります。

WADLを使用すると、コード、テスト、およびドキュメントを生成できます。実際、WADLを利用する非常に便利なツールはほとんどありません。ここでいくつかの例を見ることができます。フィールディングの論文で説明されているように、「純粋な」RESTの問題は、ハイパーメディアをサポートするクライアントを作成することです（たとえば、Java Swingベースのクライアントアプリケーションを作成することを想像してください）。WADLを使用すると、このタスクは完全に自動化され、私の見解では大きな利点になります。テストも簡単になります。

説明する前に、ほとんどの純粋なREST過激派はそれを地球の果てまで嘲笑するだろうと言わせてください。私はむしろ何かを成し遂げたいので、私は彼らに同意しませんが、あなたが知っているように。

WADLはWebサービスAPIの説明であり、WSDLがSOAPタイプのWebサービス用であるのと少し似ており、RESTfulインターフェイス（WSDLが苦手なもの）とより調和するように設計されています。

私の経験での主な使用法は、サービスを呼び出すことができるクライアントコードを生成できるようにすることです（非常に大きなAPIの場合は便利で、文字通り作業時間を節約できます）。また、RESTのようなインターフェイスを文書化する目的も果たします。

RESTはWADLについて何も指定していません。

RESTサービスを公開する場合、最良の方法はWADLを生成し、コンシューマーと共有することです（SOAPベースのWebサービスのWSDLと同様）。WADLは、サービスをすべてオンプレースで記述するために使用されます。

WADLを使用する必要はありません。ただし、複雑な既存のアプリケーションを使用していて、EJB / SOAPサービス呼び出しを置き換えることによってRESTサービス呼び出しを実装する場合は、WADLを使用することが非常に安全で適切な方法です。WADLを使用してクライアント側のJavaスタブを生成すると、サービスと同期します。

wadl2java mavenプラグインを使用して、WADLファイルを使用してクライアント側のJavaスタブを生成できます。