1、定義：常規的WEB API就是指使用HTTP協議通過網絡調用的API；
其實就是一個WEB系統，對外提供給別人調用的API，這種調用通常是程序的方式，而不是簡簡單單的瀏覽器中輸入URL訪問。
像我們常規使用的WEB Service、c#的一般處理程序、WCF都屬於WEB API、以及Java中的響應Ajax的Servlet都算是web api
2、使用原生HTTP協議的好處？
HTTP協議的好處就是規模大而且全世界認可，畢竟大家都用了這么多年了，你公開的web api如果嚴格遵守HTTP規范的話，那么全世界的設備或程序都可以遵照http的標准方式訪問你的api，調用更加簡潔一致；而HTTP協議內部的URL直接指向一個資源，協議的Method分別有GET（獲取）、POST（添加）、DELETE（刪除）、PUT（更新）等操作；
假如不嚴格遵守HTTP的resutful風格也不是說什么都干不了；例如一個項目全部是自己公司一個團隊開發的，對資源的增刪改查操作清一色地使用AJAX的GET/POST方式結合json封裝各種crud的請求參數包的方式，而根本不用HTTP原生的POST、DELETE、PUT、GET方法，我們可以叫這種風格為 “一蓋（GET）到底或一炮（POST）到底”，本來這樣開發封裝參數包的方式也是非常靈活的，事實上很多系統都是這么干的；如果全是自己公司內部團隊或小范圍的幾個熟悉的團隊研發，這種一炮到底的風格並沒有什么問題，而且還非常靈活；
但是你要公布WEB API給世界上千千萬萬的第三方使用的時候，尤其這些第三方用的什么技術和什么硬件事先你都不知道（比如一家大的電商網站想往外公布一些webapi獲取它的產品信息，這個時候他是不知道將來會有誰來調用這些webapi的，更不知道未來調用方使用的技術等），將來調用的第三方更可不可能知道你公布的奇怪的參數包的格式，即使你給了說明文檔或者調用的代碼示例，人家解析起來應該也很費力（至少要多加幾行解析你個性化參數包的代碼），而不是像大家都嚴格遵守的標准HTTP協議那樣解析起來很便捷，例如很多硬件設備自帶的能解析Http的程序能解析標准協議但是不能保證人家能解析我們個性化的參數包，即使能解析也得多加不少代碼，而不像解析原始請求那么簡單；
3、RESTFUL架構風格？
既然知道了嚴格遵守HTTP協議的好處后，那么繼續說下RESTFUL，RESTFUL架構風格網上介紹的很多，比如asp.net webapi學起來也挺簡單，畢竟vs都有示例代碼，比較郁悶的是一開始學習這東西時雖然知道這樣做但是並沒有明白為啥要這樣做（我用ajax結合ashx或jsonresult的方式也能工作啊）；
REST（Representational State Transfer，簡稱REST），HTTP是一個協議，協議內部包含URI、請求類型、消息長度、希望返回數據的類型以及消息體等信息，而這其中的URI叫統一資源定位符，說白了是針對資源的，而對資源操作無非就是增刪改查，這些操作都是在服務器端的，而返回給請求的客戶端的數據無論是json還是xml都是一種需要展示的信息或操作的結果而已，其實HTTP來回無非在傳達client給server的命令和server給client的請求結果去顯示而已；對於常規的增刪改查Http早已經自帶了POST/Delete/Put/Get等操作，當然還有head等等，如果我們嚴格遵守了這些面向資源的URI，然后剩下的操作通過http的命令來處理的話，那么就已經能輕松的做到將展示狀態在服務器端和客戶端之間來回傳輸，雖然“一炮到底”的風格也啥都能做，但是解析起來肯定沒有原生HTTP規則來的通用，因此將能更好支持REST的架構稱之為RESTFUL架構（是更好地支持，因為一炮到底的架構也不是支持，只是不夠優雅不按照通用標准玩而已），當然RESTFUL架構除了這些還有很多別的規則需要我們遵守(例如url要清晰名了一看就知道是什么資源)。尤其是公布對外的api的時候，嚴格准守restful風格會讓使用你的api讓人用起來得心應手。
4、而asp.net web api天生就是根據restful風格來的，所以說你會asp.net web api編程那你多少肯定已經知道rest和restful是怎么回事了，畢竟每個url直接都對應到具體的資源上了，對資源的增刪改查都默認走HTTP的POST、DELETE、 PUT、 GET方式而不是自己在參數包中指定了。
5、什么時候該用RESTFUL 風格的web api?
肯定是給第三方提供編程接口的時候用了（尤其是調用的第三方還不知道是誰呢的時候），但是在選擇協議和風格的時候肯定是用http和restful風格更好些，在提供面向資源的接口時web api的restful風格絕對是很不錯的選擇，uri本身就是資源定位的，而http還自帶增刪改查的命令字，這樣寫出來的api接口全世界都好理解，例如獲取產品信息的接口，產品就是資源、獲取人員信息的接口人員就是資源，說白了URI是按照資源來切分的;如果是自己內部團隊搞的soa架構或者是已知的能相互溝通的團隊那用傳統的清一色的post或get也沒啥問題，畢竟這樣靈活，大伙這么多年都用慣了；
6、為什么要使用微服務？
webapi除了公布資源之外還可能是一個復雜的算法而不是一個數據資源，例如一個業務算法、數據算法等，這時候就不適合使用面向資源的概念，雖然也能用web api來實現，但是思路應該從數據資源轉向抽象的功能、業務算法等，為了達到松耦合的目的，資源和資源是相互分開單獨處理的，而業務功能服務也是同樣道理，總不能一個服務修改了或升級了導致原來別的服務受影響、或者使現有的調用方不好用了，所以要將不同的服務功能也細化后拆開達到一個微服務的形式，這樣以后一個服務發生變化以后別的服務照常運行（艙體隔離的原理：據說鄭和下西洋的船就用了這個智慧，一個船艙漏了船不至於沉到海里），而不是逼着客服去升級程序，因為客戶可能並不需要你這個變化的服務或者人家壓根就沒有調用過你修改的這個服務，在代碼層面也不涉及到編譯問題或者引用不到的問題，這就是微服務的好處，當然如果從廣義上講服務也可理解為資源的話，那么微服務和restful確實是有交集的，但是從對資源增刪改查的操作來說微服務和面向的資源還是有些差別，RESTFUL風格是面向資源的，而微服務是按照最小業務切分的，每個最小業務中是會包含一到多個資源的。
7、將restful風格的web api和微服務落地策略？
像web api無論是用什么技術實現，只要保證你提供出去的接口是面向一個資源的，而且利用http的get、post、put、delete來實現你的增刪改查，還能根據調用方的需要返回不同格式的數據（入json/xml），那么你就已經實現restful風格了，也比較完美的實現了一個web api了，實現之后直接將引用web api的方法或簡短的代碼公布出去就ok了。
而微服務落地則需要對業務非常熟悉，將業務的各個小細節操作進行拆分，拆分的粒度就是一個業務變化了不會影響另一個業務，一個服務就干一個業務而不是一大坨好幾個業務功能耦合在一個服務接口里了，如果耦合在一起那么就會導致一個業務變了別的都跟着受影響，具體操作反應到代碼上就是提供原子方法（可以是一個rest資源或只做一件事的一個方法），在原子方法的基礎上提供業務原子服務，在架構上為服務或處理服務的代碼插件化，當然微服務就是SOA中的一個划分風格，准確說是把艙體隔離風格或蜂巢結構的風格應用到服務上了。
從為客戶端服務的層面來說，微服務是包含restful中資源這部分的；
以上是個人學習的體會分享給大家，不對的地方歡迎大家評論；