rest - WADL の取り込みが遅いのはなぜですか?

Question

私は WADL を研究してきましたが、なぜもっと広く採用されていないのでしょうか?

REST の使用率が増加しているように見えるのに、REST を使用しない開発努力が増えていることに驚いています。

その設計に根本的な欠陥があるのでしょうか?RESTful Web サービスを通常取り囲む文化にうまく適合していないのでしょうか?それともまったく別のものなのでしょうか?

Answer 1

WADL が普及しない主な理由は、SOAP と WSDL で発生したすべての問題を復活させる可能性があるためだと思います。私にとって、相互運用性の側面は、Web サービスの最も重要な側面です。
純粋な HTTP 標準を使用する RESTful な方法に従うことで、「無料で」相互運用性を得ることができます。サービスを説明するドキュメントが必要になると、このドキュメントを異なる方法で解釈するさまざまなクライアント フレームワーク (またはさまざまなサーバー フレームワーク) が存在します。異なるフレームワークが WADL からコードを自動生成すると、相互運用性の問題に再び対処する必要があります。

標準の欠如は、RESTful な方法の弱点と長所です。単純なアプローチにチャンスを与えましょう。（自動コード生成を本当に楽しんでいますが:-)）

Answer 2

Jim Webber、Savas Parastatidis、および Ian Robinson による「REST in Practice: Hypermedia and Systems Architecture」では、次の 4 つの懸念事項について言及しています。

1. WADL は Web アプリケーションの静的ビューを事前に取得します。Web はメディアタイプとコントラクトのリンクを使用します。
2. WADL ツールは、クライアント側とサービス側の抽象化の緊密な結合を促進します。サービスからアドバタイズされたリソースは、クライアントのドメイン モデルになります。
3. WADL は、それがアドバタイズするリソースとの相互作用の順序についての手がかりを提供しません。
4. WADL は、多くの場合、リソースから入手できるメタデータを複製します。

ポイント 1 と 2 は、動的クライアント バインディングと静的クライアント バインディングの引数です。WADL を使用する場合、サービスの実装者は、サービスの変更に伴うスキーマの下位互換性に注意する必要があります。WADL を使用しない場合、クライアントは応答を解釈する方法を柔軟にする必要があります。

ポイント 3 はワークフローに関するものです。WADL は、API を呼び出す順序を文書化していません。サービスがHATEOAS規則に従って実装されている場合、WADL および非 WADL サービス応答の両方が、リンクを介して順序付けの手がかりを提供します。

ポイント 4 は、HEAD および OPTIONS の結果が WADL 定義と矛盾する可能性があることを前提としています。実際には、これらの方法のいずれかが実装または使用されることはめったにありません。

多くの REST 実装は、迅速で汚いものです。私が使用するためだけに REST サービスを実装するのは簡単です。ドキュメントが必要なのは、別のチームが提供するサービスのクライアントを作成する必要があるときです。フォーマルであればあるほど良い。WADL などのコードが読めるドキュメントが最適です。

クライアントの実装者としての私の懸念は次のとおりです。

1. サポートされているクエリ パラメータとヘッダーを確認するにはどうすればよいですか?
2. リクエストまたはレスポンスのメディア タイプに関するドキュメントを見つけるにはどうすればよいですか? IANA に登録されたメディア タイプであっても、要求/応答スキーマが必要です。