在.net平台下，有大量的技术让你创建一个HTTP服务，像Web Service，WCF，现在又出了Web API。在.net平台下，你有很多的选择来构建一个HTTP Services。我分享一下我对Web Service、WCF以及Web API的看法。
Web Service
1、它是基于SOAP协议的，数据格式是XML
2、只支持HTTP协议
3、它不是开源的，但可以被任意一个了解XML的人使用
4、它只能部署在IIS上
WCF
1、这个也是基于SOAP的，数据格式是XML
2、这个是Web Service（ASMX）的进化版，可以支持各种各样的协议，像TCP，HTTP，HTTPS，Named Pipes, MSMQ.
3、WCF的主要问题是，它配置起来特别的繁琐
4、它不是开源的，但可以被任意一个了解XML的人使用
5、它可以部署应用程序中或者IIS上或者Windows服务中
WCF Rest
1、想使用WCF Rest service，你必须在WCF中使用webHttpBindings
2、它分别用[WebGet]和[WebInvoke]属性，实现了HTTP的GET和POST动词
3、要想使用其他的HTTP动词，你需要在IIS中做一些配置，使.svc文件可以接受这些动词的请求
4、使用WebGet通过参数传输数据，也需要配置。而且必须指定UriTemplate
5、它支持XML、JSON以及ATOM这些数据格式
Web API
1、这是一个简单的构建HTTP服务的新框架
2、在.net平台上Web API 是一个开源的、理想的、构建REST-ful 服务的技术
3、不像WCF REST Service.它可以使用HTTP的全部特点（比如URIs、request/response头，缓存，版本控制，多种内容格式）
4、它也支持MVC的特征，像路由、控制器、action、filter、模型绑定、控制反转（IOC）或依赖注入（DI），单元测试。这些可以使程序更简单、更健壮
5、它可以部署在应用程序和IIS上
6、这是一个轻量级的框架，并且对限制带宽的设备，比如智能手机等支持的很好
7、Response可以被Web API的MediaTypeFormatter转换成Json、XML 或者任何你想转换的格式。
WCF和WEB API我该选择哪个？
1、当你想创建一个支持消息、消息队列、双工通信的服务时，你应该选择WCF
2、当你想创建一个服务，可以用更快速的传输通道时，像TCP、Named Pipes或者甚至是UDP（在WCF4.5中）,在其他传输通道不可用的时候也可以支持HTTP。
3、当你想创建一个基于HTTP的面向资源的服务并且可以使用HTTP的全部特征时（比如URIs、request/response头，缓存，版本控制，多种内容格式），你应该选择Web API
4、当你想让你的服务用于浏览器、手机、iPhone和平板电脑时，你应该选择Web API
关于RPC、HTTP、WebService的区别
RPC(远程过程调用)是什么
- 简单的说，RPC就是从一台机器（客户端）上通过参数传递的方式调用另一台机器（服务器）上的一个函数或方法（可以统称为服务）并得到返回的结果。
- RPC 会隐藏底层的通讯细节（不需要直接处理Socket通讯或Http通讯）
- RPC 是一个请求响应模型。客户端发起请求，服务器返回响应（类似于Http的工作方式）
- RPC 在使用形式上像调用本地函数（或方法）一样去调用远程的函数（或方法）。
远程过程调用发展历程
- ONC RPC （开放网络计算的远程过程调用），OSF RPC（开放软件基金会的远程过程调用）
- CORBA（Common Object Request Broker Architecture公共对象请求代理体系结构）
- DCOM（分布式组件对象模型），COM+
- Java RMI
- .NET Remoting
- XML-RPC，SOAP，Web Service
- PHPRPC，Hessian，JSON-RPC
- Microsoft WCF，WebAPI
- ZeroC Ice，Thrift，GRPC
- Hprose
早期的 RPC
- 第一代 RPC（ONC RPC，OSF RPC）不支持对象的传递。
- CORBA 太复杂，各种不同实现不兼容，一般程序员也玩不转。
- DCOM，COM+ 逃不出 Windows 的手掌心。
- RMI 只能在 Java 里面玩。
- .NET Remoting 只能在 .NET 平台上玩。
XML-RPC，SOAP，WebService
- 冗余数据太多，处理速度太慢。
- RPC 风格的 Web Service 跨语言性不佳，而 Document 风格的 Web Service 又太过难用。
- Web Service 没有解决用户的真正问题，只是把一个问题变成了另一个问题。
- Web Service 的规范太过复杂，以至于在 .NET 和 Java 平台以外没有真正好用的实现，甚至没有可用的实现。
- 跨语言跨平台只是 Web Service 的一个口号，虽然很多人迷信这一点，但事实上它并没有真正实现。
PHPRPC
- 基于 PHP 内置的序列化格式，在跨语言的类型映射上存在硬伤。
- 通讯上依赖于 HTTP 协议，没有其它底层通讯方式的选择。
- 内置的加密传输既是特点，也是缺点。
- 虽然比基于 XML 的 RPC 速度快，但还不是足够快。
Hessian
- 二进制的数据格式完全不具有可读性。
- 官方只提供了两个半语言的实现（Java，ActionScript 和不怎么完美的 Python 实现），其它语言的第三方实现良莠不齐。
- 支持的语言不够多，对 Web 前端的 JavaScript 完全无视。
- 虽然是动态 RPC，但动态性仍然欠佳。
- 虽然比基于 XML 的 RPC 速度快，但还不是足够快。
JSON-RPC
- JSON 具有文本可读性，且比 XML 更简洁。
- JSON 受 JavaScript 语言子集的限制，可表示的数据类型不够多。
- JSON 格式无法表示数据内的自引用，互引用和循环引用。
- 某些语言具有多种版本的实现，但在类型影射上没有统一标准，存在兼容性问题。
- JSON-RPC 虽然有规范，但是却没有统一的实现。在不同语言中的各自实现存在兼容性问题，无法真正互通。
Microsoft WCF，WebAPI
- 它们是微软对已有技术的一个 .NET 平台上的统一封装，是对 .NET Remoting、WebService 和基于 JSON 、XML 等数据格式的 REST 风格的服务等技术的一个整合。
- 虽然号称可以在 .NET 平台以外来调用它的这些服务，但实际上跟在 .NET 平台内调用完全是两码事。它没有提供任何在其他平台的语言中可以使用的任何工具。
ZeroC Ice，Thrift，GRPC
- 初代 RPC 技术的跨语言面向对象的回归。
- 仍然需要通过中间语言来编写类型和接口定义。
- 仍然需要用代码生成器来将中间语言编写的类型和接口定义翻译成你所使用的编程语言的客户端和服务器端的占位程序（stub）。
- 你必须要基于生成的服务器代码来单独编写服务，而不能将已有代码直接作为服务发布。
- 你必须要用生成的客户端代码来调用服务，而没有其它更灵活的方式。
- 如果你的中间代码做了修改，以上所有步骤你都要至少重复一遍。
Hprose
- 无侵入式设计，不需要单独定义类型，不需要单独编写服务，已有代码可以直接发布为服务。
- 具有丰富的数据类型和完美的跨语言类型映射，支持自引用，互引用和循环引用数据。
- 支持众多传输方式，如 HTTP、TCP、Websocket 等。
- 客户端具有更灵活的调用方式，支持同步调用，异步调用，动态参数，可变参数，引用参数传递，多结果返回（Golang）等语言特征，Hprose 2.0 甚至支持推送。
- 具有良好的可扩展性，可以通过过滤器和中间件实现加密、压缩、缓存、代理等各种功能性扩展。
- 兼容的无差别跨语言调用
- 支持更多的常用语言和平台
- 支持浏览器端的跨域调用
- 没有中间语言，无需学习成本
- 性能卓越，使用简单
rpc是远程过程调用，你可以这么理解，就是在另外一台服务器上有一段代码（函数），你可以通过网络远程调用它。用什么协议（http，tcp，udp…），传输什么数据格式（json，xml，二进制…）你都可以自己定义。
http只是一种应用层的协议，和你要写的代码没有关系。你只需要好好的了解它，并且利用好它的特性就好了。
webservice，顾名思义这也是一种提供service的形式，只是它是通过http（web）来提供service而已。你可以基于http来提供你想提供的任意的服务，可以是rpc，也可以是restful。