目前知道的三種主流的web服務實現方案為：
rest：表象化狀態轉變 (軟體架構風格）
soap：簡單物件訪問協議
xml-rpc：遠端過程呼叫協議
下面分別作簡單介紹：
rest：表徵狀態轉移（representational state transfer），採用web 服務使用標準的 http 方法 (get/put/post/delete) 將所有 web 系統的服務抽象為資源，rest從資源的角度來觀察整個網路，分布在各處的資源由uri確定，而客戶端的應用通過uri來獲取資源的表徵。http協議所抽象的get,post,put,delete就好比資料庫中最基本的增刪改查，而網際網路上的各種資源就好比資料庫中的記錄（可能這麼比喻不是很好），對於各種資源的操作最後總是能抽象成為這四種基本操作，在定義了定位資源的規則以後，對於資源的操作通過標準的http協議就可以實現，開發者也會受益於這種輕量級的協議。rest是一種軟體架構風格而非協議也非規範，是一種針對網路應用的開發方式，可以降低開發的複雜性，提高系統的可伸縮性。
soap：簡單物件訪問協議（****** object access protocol）是一種標準化的通訊規範，主要用於web服務（web service）中。用乙個簡單的例子來說明 soap 使用過程，乙個 soap 訊息可以傳送到乙個具有 web service 功能的 web 站點，例如，乙個含有房價資訊的資料庫，訊息的引數中標明這是乙個查詢訊息，此站點將返回乙個 xml 格式的資訊，其中包含了查詢結果（**，位置，特點，或者其他資訊）。由於資料是用一種標準化的可分析的結構來傳遞的，所以可以直接被第三方站點所利用。
xml-rpc：乙個遠端過程呼叫（remote procedure call，rpc)的分布式計算協議，通過xml將呼叫函式封裝，並使用http協議作為傳送機制。後來在新的功能不斷被引入下，這個標準慢慢演變成為今日的soap協定。xml-rpc協定是已登記的專利專案。xml-rpc透過向裝置了這個協定的伺服器發出http請求。發出請求的使用者端一般都是需要向遠端系統要求呼叫的軟體。
三種方案的簡單比較
xml-rpc已慢慢的被soap所取代，現在很少採用了，但它還是有版權的，我在此就不作多介紹
成熟度上：soap在成熟度上優於rest
效率和易用性上：rest更勝一籌
安全性上：soap安全性高於rest，因為rest更關注的是效率和效能問
總體上，因為rest模式的web服務與複雜的soap和xml-rpc對比來講明顯的更加簡潔，越來越多的web服務開始採用rest風格設計和實現。例如，amazon.com提供接近rest風格的web服務進行圖書查詢；雅虎提供的web服務也是rest風格的。rest對於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而soap的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的介面設計帶來便利。所以我覺得純粹說什麼設計模式將會佔據主導地位沒有什麼意義，關鍵還是看應用場景，正是那句老話：適合的才是最好的
同時很重要一點就是不要扭曲了rest現在很多**都跟風去開發rest風格的介面，其實都是在學其形，不知其心，最後弄得不倫不類，效能上不去，安全又保證不了，徒有乙個看似象摸象樣的皮囊。
三種主流的web服務實現方案
跨域的三種主流解決方案
jsonp jsonp實現原理 主要是利用動態建立script標籤請求後端介面位址，然後傳遞callback引數，後端接收callback，後端經過資料處理，返回callback函式呼叫的形式，callback中的引數就是json。前端 我在vue中主要是通過vue腳手架中的config中的inde...
分析三種主流防火牆配置方案利弊
雙宿主機閘道器 dual homed gateway 這種配置是用一台裝有兩個網路介面卡的雙宿主機做防火牆。雙宿主機用兩個網路介面卡分別連線兩個網路，又稱堡壘主機 bastion host 堡壘主機上執行著防火牆軟體 通常是 伺服器 可以 應用程式，提供服務等。雙宿主機閘道器有乙個致命弱點 一旦入侵...
Web分頁顯示的三種實現方式
一次性查詢記錄並載入到html的table中。然後通過選擇性地顯示某些行來達到分頁顯示的目的。這是一種偽分頁，障眼法而已。只能用於資料少的情況下。一旦資料多了，十幾萬條資料載入到html中會變得很慢。而且不實時，一次載入完後資料就寫死在頁面了，若資料庫中有變化，瀏覽器端顯示的仍是上次載入過來的資料。...