Web API vs Web Service

Web API = Web Service - 服务定义，换言之 Web API + 服务定义 = Web Service。

少了服务定义会怎样？

1. 无法发现服务，从而也无法知晓服务的变更和删除。但，这样又如何？服务发现本来就是UDDI而非WSDL做的事情。
2. 无法获得数据类型的定义。Web API在这方面使用XML或者json直接传输数据而无须预先定义，这两个都是弱类型的语言：
3. • 好处，再复杂的类型(只要不是循环引用)都轻松的搞定
   • 不好不坏，基础类型都有，通用性十足（WSDL也有，而且只需要做一次）
   • 坏处，没有动态语言功底的环境，每次都需要解析比较吃力（WS有了WSDL，这种事情只需要做一次）
4. 无法获得消息结构的定义。正如2中描述的那样，如果描述一个数据那么复杂，又何必为了它建立一个公开接口定义？相应的，如果描述很容易，也没有必要去事先定义。
5. 无法定义多个操作。。。对于调用API的人来说没有任何作用。
6. 无法定义多个站口/通讯协议。这也是个赘饰。

少了服务定义又会怎样？

1. 仍然需要一个服务的源来暴露服务。作为一个服务提供商，这是理所当然要做的事情。
2. 数据类型的定义。只要不出现循环引用，一切都简单到不能更简单。
3. 服务接口的定义。也许我们无法提供在线的代码框架生成，但我们可以提供手册+现成的接口调用代码。

当然具体到WS的代表SOAP与WebAPI的代表json。PK不会发生在Soap->Http Header VS Http Header(结果一样)，就只有Soap Body->Http Body->XML vs Http Body->json了。这两者没什么可说的，json基本上是完胜。

所以，一个通常的服务提供商，json形式的Web API加上统一的源管理，胜过soap+http的Web Service。不要扯什么安全性，大家都是http基础；如果认为json能够跨域就叫“不安全”，那他应该弄明白怎么样才能跨域。