最近george reese正在把他和adrian cole共有的一些在雲端使用各種soap和rest api的經驗寫出來，對此我們早先也做了報道。現在george的原作在twitter和各類部落格中激起了大量的辯論。例如，william vambenepe同意他大部分的言論，但有一小部分持不同意見，比如說對json和xml的支援：
\
\\
而william也不同意george聲稱rest比soap要好：
\
\\未必對所有整合專案來說都是正確的，但在雲api的背景下，我同意這一點。只要它是「實用的rest」，而沒有為了取悅rest警察而做些很傻的扭曲。
\
有意思的是，有乙個看法引起了william的注意．．．
\
\\
\\關於「提供優秀的api文件減少了我對你幫助的需求」。如果你給乙個api寫文件，你的api馬上就跟rest沒關係了。在restful系統中真正的約定是**型別，而不是api文件。我建議你把那部分放到「缺點」！請看：
\
然而，stu charlton引起了可能是最熱烈的討論，並在他的關於api的麻煩的文章中總結成了5點。
\\rest api是乙個好心辦壞事的例子。rest的目的就是消除特定的api，而不是滋生它們。\
如果誰告訴你不應該為rest api寫文件，他們實際是在說你不該寫api，而不是說你不該寫文件。\
話說回來，說你不該寫api的rest的擁躉也有點傻，因為他們也沒有提出什麼好的選擇。定製的**型別算不上乙個。\
這樣說來，以我的觀點，在我們有一兩個可利用的普遍**型別之前，對80%的rest api來說，我們只是自尋煩惱。\
我已經差不多放棄擁護rest了，因為現在來看不太可能。人們只是想發布一些只能用6個月的api，而不是構建可以進化10年以上的系統。\
\\
\\rest 所製造的問題（……）在於，現在隨便乙個api設計者都自認為稱得上是分布式計算的大師，像個藝術家般決定把版本和憑證之類的東西放在什麼樣的地方，憑自己喜好把操作和查詢編碼到一堆報文頭、符號、查詢引數、報文體等等之中。要是你問我的話，我得說rest製造了軟體工業中前所未有的**。
\
stu最後以他認為應用rest導致的一些規則變化作為總結：
\ 你不能假設你的服務的終端使用者是乙個程式設計師（或瀏覽器）。stu的看法是，如果你的目標是讓程式設計師學習你的api，那就沒有必要使用rest。\
你不能假設只有乙個站點會實現你的介面。「web的整體精神是分享資訊——發布乙個api造成作為發布者的你在全權控制的假設。其實是消費者——客戶端**本身控制著什麼樣的資訊如何被消費和操作。」\
「需要文件化的介面語義是你用來描述你的資料和鏈結的**型別。你的url的結構絕不應該成為這個語義的一部分。」\
「但是在定製的**型別裡這麼做說明你是唯一乙個實現你自己的介面的人。當然每個**型別總要有個開始，但是這確實沒什麼幫助，除非你理解其他人可能會實現你的介面而不只是與之會話。\
他提出的最後一點規則的改變值得單獨提出來因為它多年來都是很多爭論的主題:
\
\\我們所能希望的最好的情形是有人或組織能承擔這個責任提出一兩個通用**型別以及指南，來幫助描述和文件化乙個資料web的介面給程式設計師使用。如果你願意可以稱之為描述語言。一些rest的擁躉不喜歡描述語言這個想法，而我認為這實際是80/20的比例，如果開發者真的打算用它原本的用法去使用這個架構。
\
那麼你是怎麼想的？我們是光缺少良好定義的設計好的rest api的規則，還是像jj暗示的那樣這是乙個失敗的運動？
\檢視英文原文：yet more trouble with rest apis?
筆記 REST API 設計
evernote export body,td 04 07 2015 saturday 15 50 04 07 2015 saturday 17 48 liker.xu head 安全 冪等 options 安全 冪等 put 寫操作 更新或新增資源 冪等，多次插入或者更新同乙份資料，不安全 pos...
rest api入門介紹
隨著 rest 成為大多數 web 和 mobile 應用的預設選擇，勢必要對它的基本原理有所了解。在它提出十多年後的今天，rest 已經成為最重要的 web 應用技術之一。隨著所有技術朝著 api 方向發展，它的重要性有可能持續快速地增長。每門主要程式語言現在已經包含構建 restful web ...
REST API基礎介紹
1 介面中盡量使用名詞 2 使用post請求資源 3 delete請求刪除資源 eg.get notes id 獲取某個指定id的筆記資訊 1 rest resource representational state transfer 資源在網路傳輸中 以某種 表現形式 進行 狀態轉移 ps 網際網...