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

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

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

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

SOAP、REST、および人々の創造性

各リソースは異なるメッセージで消費される可能性があるため、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を頻繁に使用し、本当に気に入っています。これは、主にWeb APIの素晴らしいライブコンソールとドキュメントを生成できるSwagger UIが理由です。

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

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

WEB API RESTへのクライアントの生成

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

WebApiProxyなどのプロジェクトは、C＃およびJavascriptを実行するクライアントを簡単に生成できます。

WEB API RESTの規約

開発者の生活を楽にするために、Web API RESTの振る舞いの規則を定義するのが良いでしょう。この分野で私が知っている最善の努力は、非常に良いApigee-Web Api Design電子ブックです。電子書籍は、APIの設計方法に関する聖書やマントラを作成する試みではなく、Twitter、Facebook、Linkedin、Googleなどの大規模なWeb REST APIで見られる規則のコレクションです。

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

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

一方...

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

要約すると、SOAP Webサービスは通常、ソリューションを統合するために使用されると言えますが、RESTサービスは同じソリューションの部分間の通信を提供するのにより適しています。

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

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

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

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

皮肉なことに、これは私がでノードを使用してきた分野の一つである多く、クライアントとして汚い実装を受け入れる柔軟十分だった、と私はより良い仕事を私の適応ペイロードに対して、単純なクライアントを書くことができますという理由だけで、翻訳サービスなど。例：C＃はJSONテキストを取得します。JSON.Netを使用して、WSDLインポートを使用できなかったときに実際に機能したと定義したオブジェクト表現に変換します。

実際には、これは頻繁に起こります。

ここでの答えの多くは素晴らしいものですが、答えは非常に簡単だと思います。あなたは仕事のために間違ったテクノロジーを見ているのです。

SOAPサービスを構築する場合は、WCFに固執する必要があります。まだ非常に強力なフレームワークであり、マイクロソフトはまだ積極的に開発しています。将来どこに行くかについて発表することはなく、これを念頭に置いて作成されました。Web APIは、WCFに取って代わるものではありません（ただし、おそらくWCFよりもトレンディです）。

Web APIは以前はWCFの一部でしたが、他のWCFテクノロジーとは実際には適合しなかったため、ASP.NETファミリに完全に移行しました。Web APIは、転送プロトコルよりもアプリケーションプロトコルとしてHTTPを使用することにずっと関心があります。Web APIでは、HTTP動詞が重要です。WCFでは、HTTPは単にSOAPプロトコルを有効にする役割を果たします。

Web APIが特定の目的のために作られたものではないという理由でWeb APIを非難しないでください。