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