比如說，這個restful風格。從網上的資料大概知道，它首次出現在 2000 年 roy fielding 的博士**中，他是 http 規範的主要編寫者之一。
對於http來作為通訊，我認為是乙個不錯的方案，因為目前大多語言的標準庫應該都是提供了http的支援，而且http這種無狀態的請求，也容易接受。比起socket通訊，相對要易用，而且測試也比較方便甚至可以直接用瀏覽器來訪問。
不過，對於restful，我並不是非常喜歡，總感覺它有點彆扭。
一種軟體架構風格，設計風格而不是標準，只是提供了一組設計原則和約束條件。它主要用於客戶端和伺服器互動類的軟體。基於這個風格設計的軟體可以更簡潔，更有層次，更易於實現快取等機制。
在 rest 樣式的 web 服務中，每個資源都有乙個位址。資源本身都是方法呼叫的目標，方法列表對所有資源都是一樣的。這些方法都是標準方法，包括 http get、post、put、delete，還可能包括 header 和 options。
它的乙個重點在於，充分利用了http的post，put，delete等方法的含義。
rpc（remote procedure call protocol）就是遠端呼叫。遠端呼叫免不了訊息通訊，所以本質上都是一種通訊。rpc應該有各種各樣的協議，基於或擴充套件與socket，http等協議。前面說了，如果不是為了速度，應該不大會有人用socket，畢竟略有開發難度。比如**的hsf也是基於http的通訊。
所以，最簡單的想法，應該就是把http協議當做rpc來用。比如我們把**作為乙個藉口，傳入的引數作為函式引數，response的資料作為返回資訊。這其實就是乙個呼叫。
所以，我一直不明白的是，用這種介面和一般的函式庫呼叫一樣，感覺很容易理解。而且目前的訊息通訊，用json基本可以通用。為什麼還需要restful這種協議呢？
我覺得restful和rpc最大的區別應該就是物件導向了。對於restful而言，這個鏈結其實就是個物件，我可以增刪改查，這些東西是http自帶的。
但似乎更多的操作我們沒法通過這幾個方法來描述呢，那不就又落回到rpc了麼。
我覺得可能很多人只知道get和post，因為現在最常用的就是get和post了。雖說這應該是違背了http設計的初衷。
如果我們用上restful，那麼開發者就需要理解另外幾種不常用的方法。當然，如果你說可以有現成的庫啊，那當我沒說。
restful使用了http的4xx，5xx的那些錯誤定義。相當於http定義了這些錯誤，供開發者識別。
但實際上，業務肯定會自己定義錯誤標示。那麼，你不覺得那些編號反而會有干擾。不知道的還以為是網路連線有問題，沒想到只是請求錯誤。
基於JSON的RESTful介面協議
xml的格式可以改為json格式 對於restful api來講，我們已經解決了傳輸協議的問題 基於http，協議約定問題 基於json。最後要解決的是服務發現問題。有個著名的基於restful api 的跨系統呼叫框架叫spring cloud,在spring cloud中有乙個元件叫eureka...
基於Restful風格的API操作
索引操作 新增索引 put index 索引 查詢索引 get index 刪除索引 delete index 對映管理資料管理1.通過id查詢 語法1 通過id查詢所有 select get 索引名 型別 id 語法2 通過id查詢部分 select 欄位1,欄位2 get 索引號 型別 id?s...
Http請求Restful風格的遠端呼叫
由於最近專案中用到了工作流，由於工作流是別的專案組開發的，所以在專案的開發過程中，用到了兩個專案之間的方法的遠端呼叫。所以下面我們一起來了解一下具體的操作。在方法的呼叫過程中存在兩種形式post方式請求呼叫和get方式請求呼叫，下面我們來看一下這兩種方式的具體的請求寫法。try catch ioex...