在.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。