web-dev-qa-db-ja.com

Web APIのWSDLタイプサポートがないのはなぜですか？

だから私は.Net WebApiを始めたばかりで、すぐに気づいていることの1つは、APIの外観と消費方法を定義するコントラクトがないことです（各アクションからのリクエスト/レスポンス）、これは通常、 WCF/SoapのWSDL。

これは非常に価値のあるものであり、APIの利用者の生活を非常に楽にするものであるように私には思えます。

ない理由はありますか？私が知らないプログラミングのパラダイムや原則はありますか？作成する方法はありますか？

c#asp.net-mvcweb-api
33
shenku

SOAP、REST AND PEOPLE'S CREATIVITY

SOAPはWSDLのような説明ドキュメントを必要とします。これは、各リソースが異なるメッセージで消費される可能性があるため、リソースを操作できる可能な名前/メッセージへの制約に関するプロトコルの定義はありません。

たとえば、SOAPの場合、クライアントがユーザーを操作できるWebサービスでは、次のようなさまざまなメッセージでユーザーを作成する操作を公開できます。

addUser
createUser
insertUser

もちろん、おもしろいWebサービスのメソッド名がたくさんあるので、これらはサンプルメッセージのほんの一部です。そこには本当にクリエイティブな人々がいます。

一方、RESTの原則を尊重するWeb APIを使用して基盤となるシステムを公開している場合、クライアントは、ユーザーという名前のリソースがあることを知る必要があります。この方法でユーザーを作成できる可能性

POST /Users

そして、これは、SOAPまたはWeb API RESTを使用して公開する操作ごとに発生します。

SOAPプロトコルであり、実行できることまたは実行できないことを制限します。また、RESTスタイルアーキテクチャであるため、実行方法の多くのオープンポイントを残しますREST Web APIを公開および使用する方法の規則を定義する取り組みがあります。


Web API RESTの説明

Web apiを記述する方法のフィールドREST引用できます Swagger 。Web api RESTのようなWSDLを作成する試みではありませんが、 Web API RESTを記述するためのオープンスタンダードを作成するための良い試み。

Swaggerは、RESTful Webサービスを記述、生成、消費、および視覚化するための仕様および完全なフレームワーク実装です。

私はSwaggerをたくさん使用していて、本当に大好きです。主な理由は Swagger UI を使用すると、Web APIの素敵なライブコンソールとドキュメントを生成できます。

Swaggerの実装には、C＃、Java、Python、Rubyなど、ほとんどの言語で多数あります。

ASP .NET Web APIを使用している場合、Swagger仕様を自動生成するいくつかのプロジェクト-- Swagger.NET などがあります。


クライアントをWeb API RESTに生成する

動詞の限られたセット（GET、POST、PUT、DELETEなど）のようなRESTの制約は、クライアントライブラリをWeb API RESTに生成するのにそれほど難しいものではないためです。

WebApiProxy のようなプロジェクトは、C＃およびJavaScriptを使用してクライアントを簡単に生成できます。


Web API RESTの規約

開発者がより簡単であるように私たちの生活を維持するために、Web API RESTの動作方法のいくつかの規則を定義します。この分野で私が知っている最善の努力は非常に優れています Apigee-Web Api Design ebook 。e-bookは、APIの設計方法に関する聖書やマントラを作成する試みではなく、大規模なWebで観察される規則の集まりですREST apis、 Twitter、Facebook、Linkedin、Googleなど。

23
giacomelli

簡単に言うと、SOAPはわかりやすいように設計されているためです。通常、SOAPエンドポイントには、提供する操作とデータがどのように表示されるかを示すwsdlが含まれます（埋め込みにより） XSD）は、各操作で取得または返されます。
この自己記述性のため、Visual StudioなどのアプリケーションがそのためのWebサービスプロキシを生成することが可能です。

さらに、SOAPで暗号化またはトランザクションの動作を使用できるようにするSOAP（WS- *仕様）にはいくつかの拡張機能があります。アイデアは、エンタープライズクラスのWebサービスを作成するためのワンストップショップとしてSOAPを使用できるということです。

一方...

WebAPIはRESTサービスを提供するように設計されています。 RESTの通信形式は通常JSONまたはプレーンxmlです-本当に問題ではありませんが、プレーンテキストでもかまいません。 RESTサービスは完全に異なる哲学に従います：AJAXソリューションの一部としてクライアント側のスクリプトによって、またはモバイルデバイスによって簡単に利用できるように、それらは軽量であることを意図しています。
そのため、自己記述性を含め、式典のレベルを最小限に抑える必要があります。また、たとえあなたが望んでも、RESTサービス（JSONなど）で使用されるほとんどの通信形式には、コンテンツを正式に記述する方法がありません。

要約すると、SOAP Webサービスは通常、ソリューションを統合する（異なる可能性がある）ために使用されますが、RESTサービスは同じソリューションのパーツ間の通信を提供するのに適しています。

5
Astrotrain

SOAP/WS- *とRESTful APIは同じではありません。 SOAP/WS- * WSDLサポートAPIを構築する場合、Microsoftスタックで選択するツールはWCFであり、HTTPバインディングオプションでマウントされます（XMLおよびJSONバインディングオプションがあり、XMLはWSDLサポートオプションです）。

実際には、別の実装言語またはプラットフォームからWSDLを使用することには問題があります。 WS- *セキュリティ層はさらに上にあります。

私自身の経験は主に.Net、Node、JavaおよびPHPでした。子タイプの詳細を定義する必要がある場合、または定義として「オブジェクト」を使用する場合、控えめに言っても問題が生じます。これを超えて、ほとんどの場合、SOAP/WS- *のすべてをツールに大きく依存して理解している人はいません。このツールには多くのオーバーヘッドがあり、システムによって動作が異なります。

これらは、人々がより単純な実装を試そうとした理由の一部です。 RESTサービス（ala Web API）は、オブジェクト/状態に関連するエンドポイントを提供します。JSON形式で表される単純なオブジェクト構造のセットを定義する方が簡単であり、これらの構造に対して使用するエンドポイントよりも機能しないエイリアン環境からWSDLを使用してから、問題を掘り下げて回避してみてください。

皮肉なことに、これは翻訳サービスとしてNode in lotで使用した領域の1つです。これは、ダーティな実装をクライアントとして受け入れるのに十分な柔軟性があるためです。 、そして私は適応したペイロードに対して単純なクライアントを書くことができました。EX：C＃はJSONテキストを取得します。これはJSON.Netを使用して、WSDLインポートを使用できなかったときに実際に機能したと定義したオブジェクト表現に変換します。

実際には、これはよく起こります。

1
Tracker1