WADLを使用する理由は何ですか？
RESTfulを説明するために、すべてのリソースに独自のURIがあると言えます。 HTTP GET、POST、PUT、およびDELETEを使用して、これらのリソースを操作できます。すべてのリソースは代表的なものです。リソースを使用したい人は誰でも、ブラウザまたはRESTクライアントを介して使用できます。
それがRESTfulアーキテクチャの主なアイデアです。このアーキテクチャにより、インターネット上のサービスが可能になります。では、なぜこのアーキテクチャにはWADLが必要なのでしょうか？ WADLは、標準のHTTPでは提供されないものを提供しますか？ WADLが存在する必要があるのはなぜですか？
WADLの目的は、契約を定義することです。契約は、ある当事者が別の当事者に電話をかける方法を指定します。
Webアプリケーションをゼロから作成する場合、契約とWADLは不要です。
システムを他のシステムと統合し、開発チームと明確に通信できる場合、契約とWADLは不要です（電話をかけて明確にすることができるため）。
ただし、複数の異なる企業（または連邦機関）によって管理されている他の複数の複雑なエンタープライズシステムと複雑なエンタープライズシステムを統合する場合は、可能な限り厳密に定義された通信契約を持っていると信じてくださいyou wantその後、WADLまたはOpen Specificationが必要です。ひどく必要です。
エンタープライズのバックグラウンドが弱い人は、IT全体を独立して開発された分離されたWebアプリケーションの集まりと見なす傾向があります。しかし、企業の現実は難しい場合があります。統合する必要のあるアプリケーションの開発者に電話をかけたり、書いたりすることさえできない場合があります。メンテナンスされていないレガシーアプリケーションと通信する場合があります。実行されるだけで、適切に通信する方法を理解する必要があります。 このような条件では、お尻が節約されるため契約が必要です。
実際、クライアントの生成は契約定義のマイナーな機能です。ただのおもちゃです。契約は、統合ルールを明確に伝えるために、悪いコミュニケーターを強制します。これが、WADLやOpen Specificationなどを使用する主な理由です。
WADLを使用するということは、やり取りするデータ/ドキュメントを実際に定義するのに十分なほど丁寧であることを意味します。いくつかのXMLフラグメントを渡すとします。実際には、それらは定義済みスキーマの一部である可能性があります。
コードを生成するためにDLを使用するかどうかはあまり重要ではありません。私の主観的な意見では、ビジネスパートナー間のインターフェイスについて正式な契約を結ぶことが重要です。渡されたものがis明らかであっても、誰かが前のインターフェースを変更した場合、後で誰が何を修正する必要があるかを識別するのに役立ちます。
データ形式は、動詞名と同じくらいインターフェイスの一部です。
WADLは、コードジェネレーターを使用してWSDLに基づいてクライアント側コードを作成することが一般的であるSOAPの世界から来ている人々にアピールします。サーバーエンドポイントに結合されたクライアントコードを作成するため、このメカニズムはRESTで有用ではないと思います。
メディアタイプを適切に定義し、それらのメディアタイプ内でハイパーメディアを使用する場合、WADLは必要ないと考えます。使用可能なエンドポイントの説明は、メディアタイプ定義自体に含まれています。そして、あなたが自分自身に言っているのに、application/xmlに利用可能なハイパーリンクに関する情報が含まれていない場合、私はBINGOと言います。そのため、application/xmlとapplication/jsonはRESTに適したメディアタイプではないと思います。私はXMLやJSONを使わない、ただ汎用的なメディアタイプ名を使わない、と言っているのではありません。
WADLのもう1つの魅力は、RESTサービスを文書化することです。残念ながら、WADLはサーバー側のエンドポイントを文書化しようとするため、開発者は間違った道をたどります。 RESTサービスの文書化は、主にメディアタイプに焦点を当てる必要があります。クライアント開発者は、ルートURL以外のURLを知らなくてもRESTクライアントを作成できる必要があります。
WADLを使用すると、コード、テスト、およびドキュメントを生成できます。実際、WADLを利用する非常に便利なツールはほとんどありません。いくつかの例を参照できます こちら 。 Fieldingの論文で説明されている「純粋な」RESTの問題は、ハイパーメディアをサポートするクライアントを書くことです（たとえば、Java Swingベースのクライアントアプリケーションを書くことを想像してください）。私の見解ではそれは大きな利点ですテストも簡単になります.
説明をする前に、最も純粋なREST過激派は地球の果てまでそれをdeります。でもそうですね。
WADLはWebサービスAPIの説明です。WSDLはSOAPタイプのWebサービスに似ていますが、RESTfulインターフェース（WSDLが苦手なもの）とより調和するように設計されています）。
私の経験における主な使用法は、サービスを呼び出すことができるクライアントコードを生成できるようにすることです（非常に大きなAPIで、文字通り何時間もの作業を節約する場合に便利です）。また、RESTのようなインターフェースを文書化する目的にも役立ちます。
REST servicesを公開する場合、最良の方法はWADLを生成し、コンシューマーと共有することです（SOAPベースのWebサービス）のWSDLと同様）。WADLサービスをすべて適切に記述するために使用されます。
WADLは使用する必要はありません。ただし、複雑な既存のアプリケーションを使用していて、EJB/SOAPサービスコールを置き換えることでRESTサービスコールを実装する場合は、WADLを使用することは非常に安全で優れたプラクティスです。 WADLを使用してクライアント側を生成しますJavaサービスと同期するスタブ。
Wadl2Java mavenプラグインの助けを借りてWADLファイルを使用して、クライアント側Javaスタブを生成できます。