問題タブ [wadl]

現在、RESTfull アプリケーション用のクライアント API を作成するためのオプションを検討しています。これまで、すべてのアプリケーションがビジネス層に接続できるようにするための WCF サービスがありましたが、それに不満を募らせています。

Web 用のほとんどのインフラストラクチャ (html および json 要求) は既に用意されていますが、他のアプリケーションからサービスにアクセスする必要があります (一部はメインの Web アプリ モデル ライブラリにリンクされ、その他はリンクされません)。

こことここでWADLについて読んでいますが、有益だと思われます。クライアント ライブラリである wadl を生成し、それを使用して JavaScript URL をチェックできます。

他の人が何を使用したか、何が機能し、何が機能しなかったかを知りたいです。

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

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

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

WADL ファイルの素晴らしい例を読みました。WADL2Javaツールもチェックアウトしました。

しかし、WADL 形式の完全な仕様が見つからないようです。主に、ファイルのさまざまな部分が互いにどのように関連しているか、および参照を使用して重複を減らすことができるかどうかを扱っています。

後で

leppieは公式の回答を得ましたが、その文書はちょっとひどいものです。誰でもより良いリファレンスを持っていますか?

Ruby on RailsのRESTfulメソッドで期待されるパラメーターを公開する方法はありますか？SOAPを使用するとWSDLを使用できますが、RoRはRESTfulサービスにWADLまたはWSDL 2.0を実装しますか？編集：ActionWebServiceを使用したSOAPベースのソリューションを知っています。https://wadl.dev.java.net/に相当するRoRを参照していました

WADL ファイルで記述された RESTful Web サービスにアクセスするための C# コードを、 wadl2javaの動作と同様の方法で生成できるコード ジェネレーターを探しています。

いろいろ検索していると、Google Code でrest-api-code-genプロジェクトに出くわしましたが、最新のソースは実際には C# をサポートしていますが、REST Describe & Compile デモ サイトはサポートしていません。(C# ボタンはありますが、無効になっています。)

ソースをダウンロードして最新バージョンで独自のサーバーをセットアップできることはわかっていますが、必要なのはコマンド ライン ツールであり、Google Web Toolkit に依存する Web アプリケーションではないため、そうしたくないと考えています。同じソース コードに基づいて独自のコマンド ライン ツールを作成することもできると思いますが、それが既に行われている場合、または他のツールで作業できる場合は、むしろ避けたいと思います。

それで、私は疑問に思っています、そこにそのようなツールはありますか？

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

それが RESTful アーキテクチャの主な考え方です。このアーキテクチャにより、インターネット上のサービスが可能になります。では、なぜこのアーキテクチャに WADL が必要なのでしょうか? 標準の HTTP にはない WADL の機能は何ですか? WADL が存在する必要があるのはなぜですか?

私が目にするほとんどの REST インターフェイスは、URL、メソッド、受け入れられた入力、および返された結果を説明する単純な Web ページで記述されています。たとえば、Amazon S3やTwitter APIドキュメントなどです。

Amazon や Twitter では、人間が読める形式で十分なようです。しかし、REST API を機械可読形式で記述している企業はありますか? はいの場合、どれですか？

WSDL 2.0 クレームはREST を記述することができます。WADLは、REST サービスを記述するために明示的に作成されます。WSDL 2.0 と WADL はどちらも、従う傾向がかなり小さいようであり、記述ドキュメントを作成して維持する努力に対する見返りはほとんどないようです。実際の例を特定することで、基本的にこの仮定を検証または否定することができます。

サービスの記述に WSDL/WADL を使用していますか? 他のサービスを利用するために WSDL/WADL に依存していますか? 選択したツールは、現時点でいずれかをサポートしていますか? 広く使用されている使用可能な REST サービスの例で、詳細が機械可読形式で示されているものはありますか?

• WSDL 2.0: www.w3.org/TR/wsdl20/
• WADL www.w3.org/Submission/wadl/
• XRD www.oasis-open.org/committees/download.php/35274/xrd-1.0-wd10.html

3 つすべてを REST API 記述子として使用できます。違いは何ですか？私はこれが激しい質問であることを知っていますが、私は単に比較をしたいだけで、炎上戦争ではありません:P

私はあいまいなRESTAPIを持っています（これは特定の問題ではなく、あいまいさのアイデアを与えるだけです）：

.htaccessファイルには、一般的な$ {product_name}バージョンの前に、より具体的な「コマンド」フォームがリストされており、最初の一致が優先されるため、これを回避してきました。ただし、現在はWADLを作成していますが、APIがあいまいなため、選択したツールがWADLを使用する際に問題が発生しています。私の質問は次のとおりです。

a）WADL仕様は、あいまいなAPIを有効に表現できるかどうかを示していますか？

b）ツールのサポート-あなたの経験では、ツールはあいまいなWADLを窒息させますか？（ambi。WADLが許可されている場合、それらは弱いツールですが、安全を確保する必要があります）

c）あいまいなREST API、特にWADLに関する経験。

好奇心旺盛な方のために、最新の仕様を以下に示します。

私が知る限り、これに具体的に対処していないとは言え、ツールがそれをどのように処理するかにかかっていると思います。

WADL提案の現在のバージョンを見ると、POSTリクエストパラメーターを（application/x-www-form-urlencodedエンコードを使用して）文書化する方法を完全に理解できませんでした。

私は野生でこのようなものを見ました：

ただし、<param style="query">の子として使用される<request>場合、仕様では次のように記述されています。

queryType属性で指定されたクエリコンポーネントメディアタイプのルールに従って表されるURIクエリパラメータを指定します。

「URIクエリ」ビットは、パラメータが本文に含まれるのではなく、URIに追加されることを示唆しているため、私を失望させました。

一方、<param style="query">の子として使用される<representation>場合、仕様には次のようなものがあります。

メディアタイプの規則に従ってフォーマットされた名前と値のペアとして、表現のコンポーネントを指定します。通常、メディアタイプ「application/x-www-form-urlencoded」または「multipart/form-data」で使用されます。

<representation>POST本文の一部としてエンコーディングで送信されるパラメーターを明示的に文書化するために要素を使用する必要がありますか？

これはやり過ぎのように見えます。仕様では「URIクエリ」と記載されていますが、前者は使えるはずだと思います。