可以這麼說，僅僅是提到rest這個詞就能引起人們的兩極分化。有段時間rest努力抗擊ws-*浪潮，隨後出現了乙個巔峰，這就像乙個障礙，rest開始走下坡路了，人們認為rest有好處，但也許沒有其他人想象的那麼多。抵制對「rest擁護者（restafarians）」相信的東西照單全收的主要倡導者之一就是jean-jacques dubray，他最近發表了一篇文章，討論他所謂的unrest。jj是這樣開篇的：
\
自2007起，\一小撮人告訴整個業界「web」可以教會大家關於分布式計算的所有東西，我們之前所做的都是錯的。四年過去了，我們只能說這一說法仍然未被證實。
jj論證的核心是rest在設計時考慮了瀏覽器，任何試圖脫離該上下文使用rest的做法無疑都是unrestful的：
\
rest在設計時考慮了終端使用者，操作使用者**：瀏覽器[...]。任何將rest原則應用於**至伺服器（agent-to-server）場景的軟體的做法都是錯的。[...]是時候該繼續前進了，這種非常規思路的複雜性沒有帶來一點好處，反而降低了生產力，它強迫所有人手工編碼那些在上一種分布式計算正規化中唾手可得的東西。\
用jj的話來說，rest「並不適用於目前的問題」，「做到restless很酷」。這意味著什麼呢？jj列出了一些規則，包括：
\
你可以自由選擇unrest，暗地裡嘲笑那些要求你對http標頭、「鏈結」、7個首字母縮寫（譯註：估計是rest api）驚嘆不已的人，他們或許還會帶著rest傳道士的口吻說你其實並不理解rest。rest只是乙個（惡）夢，unrest才是你想要做的。\
隨著人們越來越多地討論rest，尤其是在雲這樣的領域裡，如果jj是對的，那麼要改變這些做法就為時已晚了，也有可能它們本身就已經是unrestful的了？也許unrest正在回到那「糟糕的舊時代」？
\檢視英文原文：unrest as the new rest?
你的rest服務冪等嗎？
你真的了解rest api嗎？我們知道，springcloud做微服務時，服務之間的呼叫，服務的暴露使用的就是restful api，現在可以考慮這麼一種情況，加入我們有訂單服務a，支付服務b，a向b服務傳送了一次請求，但由於網路，超時等的原因，a認為b該次服務失敗，於是a又發起了一次同樣的請求，那...
到底什麼是REST中的狀態
廢話不多說，貼上群裡大佬給的例子 業務場景，乙個迷宮api，使用者登陸後在起點，用請求進行移動 有狀態的unrestful介面 使用者傳送請求，比如我要往前走，伺服器根據儲存的使用者座標進行計算，能走就返回移動成功，不能走就返回有障礙物，用同樣的引數去請求，但是每次返回的結果卻不一樣,並且資源的狀態...
什麼是REST？以及RESTful的實現
什麼是rest？rest representation state transfer 描述了乙個架構樣式的網路系統，比如 web 應用程式。它首次出現在 2000 年 roy fielding 的博士 中，他是 http 規範的主要編寫者之一。rest 指的是一組架構約束條件和原則。滿足這些約束條件...