为什么Web Api不支持WSDL类型？

因此，我只是开始使用.Net WebApi，我要立即注意到的一件事是，没有合同定义API的外观和使用方式（每个动作的请求/响应），通常采用以下形式：用于WCF / Soap的WSDL。

在我看来，这将是非常有价值的事情，并使您的API使用者的生活变得更加轻松。

有没有理由吗？我是否不了解编程范例或原理？有什么办法可以创造一个？

SOAP，REST和人们的创造力

SOAP需要像WSDL这样的描述文档，因为每种资源都可以与不同的消息一起使用，协议上没有关于可操作资源的可能名称/消息的约束的定义。

例如，在SOAP中，允许客户端操纵用户的Web服务可以在许多不同的消息中公开创建用户的操作，例如：

addUser
createUser
insertUser

当然，这些只是一些示例消息，因为我看到了很多有趣的Web服务方法名称。那里真的有创造力的人。

另一方面，如果您使用真正尊重REST原理的Web API公开基础系统，则客户端只需知道您有一个名为Users的资源，因为您有99％的机会可以在其中创建用户道路

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

因为REST的约束（例如动词的有限集合（GET，POST，PUT，DELETE等））很难为Web api REST生成客户端库。

WebApiProxy之类的项目可以轻松生成C＃和Javascript客户端。

WEB API REST的约定

为了使我们的生活更轻松，开发人员最好定义一些有关Web api REST行为的约定，我在该领域所能做出的最大努力就是编写出色的Apigee-Web Api Design电子书。该电子书不是试图创建有关如何设计api的圣经或咒语，而是尝试在大型Web REST api（例如Twitter，Facebook，Linkedin，Google等）中观察到的一系列约定。

简而言之，因为SOAP被设计为可自我描述的：SOAP端点通常包括wsdl，该wsdl描述了它提供的操作以及每个操作执行和/或返回的数据外观（通过嵌入式XSD）。
由于具有这种自我描述性，因此诸如Visual Studio之类的应用程序可能会为其生成Web服务代理。

另外，对SOAP有一些扩展（WS- *规范），这些扩展允许将加密或事务处理行为与SOAP一起使用。这个想法是，您可以将SOAP用作创建企业级Web服务的一站式服务。

另一方面...

WebAPI旨在提供REST服务。REST的通信格式通常是JSON或纯xml-尽管实际上并不重要，它甚至可以是纯文本。REST服务遵循完全不同的理念：它们是轻量级的，因此作为AJAX解决方案的一部分，客户端脚本或移动设备都可以轻松使用它们。
因此，需要将仪式的水平保持在最低水平，包括自我描述。同样，即使您愿意，REST服务中使用的大多数通信格式（例如JSON）也都没有正式的方式来描述其内容。

总而言之，您可以说SOAP Web服务通常用于集成（可能是完全不同的）解决方案，而REST服务更适合在同一解决方案的各个部分之间提供通信。

SOAP / WS- *和RESTful API不同。如果要构建SOAP / WS- * WSDL支持API，则Microsoft堆栈中的首选工具是WCF，它带有HTTP绑定选项（有XML和JSON绑定选项，XML是WSDL支持选项）。

实际上，从另一种实现语言或平台使用WSDL一直存在问题。WS- *安全层位于顶层。

在这方面，我自己的经验主要是.Net，Node，Java和PHP，我可以说，当您拥有不必定义子类型的详细信息的平台或将“ Object”用作定义，至少可以说是有问题的。除此之外，在大多数情况下，没有人真正了解所有SOAP / WS- *都高度依赖工具来使其工作。该工具有很多开销，并且不同的系统会以不同的方式运行。

这是人们希望尝试更简单的实现的一些原因。REST服务（ala Web API）提供围绕对象/状态的端点。这样的想法是，定义一组更简单的以JSON格式表示的对象结构，以及将端点用于这些结构要比尝试从无法正常工作的外来环境中使用WSDL，然后尝试进行挖掘和简化要容易得多。解决问题。

具有讽刺意味的是，这是我将Node 大量用作翻译服务的领域之一，这仅仅是因为它足够灵活，可以接受肮脏的实现作为客户端，而且我可以针对适应性更好的有效负载编写简单的客户端。例：C＃获取JSON文本，我使用JSON.Net转换为我无法使用WSDL导入时定义的实际工作的对象表示形式。

实际上，这种情况经常发生。

尽管这里的许多答案很好，但我认为答案要简单得多：您正在寻找错误的技术来完成这项工作。

如果您要构建SOAP服务，则确实应该坚持使用WCF。它仍然是一个非常强大的框架，Microsoft仍在积极开发它，没有发布任何消息让我们认为它将来会出现在任何地方，并且正是出于这一考虑。Web API绝不会取代WCF（尽管它可能比WCF更为流行）。

Web API曾经是WCF的一部分，但正是由于它与其他WCF技术并不完全匹配，它才移到了ASP.NET系列中。Web API与使用HTTP作为传输协议相比，更关心使用HTTP作为应用程序协议。在Web API中，HTTP动词为王，在WCF中，HTTP仅用于启用SOAP协议。

不要责怪Web API没有提供执行某些特定功能的能力。