1樓：
笑死了，回答問題的可以分明看出來哪些是前端哪些是後端，哪些人菜話又多。restful更多是前端提的乙個名詞，因為後端之間互動往往直接在tcp/tls上架構，http協議並非必要，所以後端訪問資料庫必須要使用所謂restful而一定不能使用其他的方式是比較罕見的。
前端就跳腳了，噴一切反對rustful風格的人，你後端自己菜做不出restful，憑什麼讓我增加工作量？
2樓：
曾經在知乎上看到乙個很形象的描述什麼 rest 。你用 rest 就幻想著你在操控資源管理器的檔案。
以這個角度來想就豁然開朗了。
Linux 一切皆檔案行。 rest 一切皆資源怎麼不行了呢？
3樓：Jett Lee
當然是夠用的，不然這玩意不會火這麼久。
由於國情，動詞只用 GET POST 其餘操作及狀態資訊在 body 裡傳參就夠了
返回使用http碼是極好的，正常資料返回200就好。
更細的粒度狀態可以在返回體的code反映
這樣，無論是前端封裝還是api管理都是方便，一目了然。
4樓：Karloku
RESTful 本身是個非常複雜得體系, 我相信真正理解並寫出完全符合 RESTful 規範的伺服器與客戶端的人並不多. 至少市面上連這樣的輪子都很少, 尤其是客戶端側的輪子.
大家現在用的比較多的「restful」風格的 api, 是去掉了 HATEOAS, 只保留了 RESTful 慣例(資源, 動詞, 狀態碼, json 等)的產物.
沒有了 HATEOAS 的 restful 風格只是風格, 慣例的存在只是為了方便開發者溝通. 他並不是人人必須遵守的規範.
再把這套風格的幾個慣例單拿出來說：
HTTP 動詞和狀態碼少得可憐, 在具體 api 中不足以覆蓋現實場景, 必然要自定義狀態碼和使用非 CRUD (GET POST PUT PATCH DELETE)的動作.
資源命名的 URL 本來沒什麼問題, 但是因為HTTP 動詞不夠用, 大多只能用 URL 來擴充套件操作, 就會遇到動作在 URL 中名詞化的命名風格之爭.
JSON 倒是好東西, 現在不管是不是 restful 風格大家都愛用.
所以為什麼不「遵守」? 確實有的人確實真的不知道 restful 風格, 但更重要的 restful 風格本來也不是聖經.
只要設計的 api 語義清晰, 並能夠讓瀏覽器以及其他根據 w3c 和 IETF 標準處理 http 的客戶端能夠不 surprised, 我覺得都是好 api.
5樓：姜勇吉
restful只是一種風格，制定的規範太過簡單，不實用。
資源url、請求方法、返回結果等的定義僅適用單一物件的增刪改餐，對於實際中的抽象資源、抽象行為，無法定義。
6樓：redblue
那些說RESTful怎樣怎樣的一定是沒見過GitHub的API設計。怎樣，是GitHub不夠複雜？還是GitHub設計辣雞？
7樓：
restful很多場景用起來非常彆扭，舉個例子，乙個查詢介面，使用者可以任選三個條件中的任意個，如果用HttpGet，就要開發出寫1+3+3=7個介面。如果用HttpPost，只需要乙個就行了，但是不符合restful的規範。
既然restful是個殘缺的方案，就不用好了，前端、後端都省事。
8樓：石頭三顆
這要看你們團隊或者專案的規範約定。
如果約定了RESTful，然後不遵守，就拉出去打一頓。
只要按照團隊約定規範寫介面，就沒有問題，RESTful又不是什麼萬能藥。
也不見得最適合你團隊和專案。
不要被所謂的規範限制了。
9樓：姬濤
給你推薦個http介面設計。
只用post，操作在url裡，請求體和返回體全在body，認證資訊在header。
HTTP 介面設計
10樓：不要禁言我
因為本身restful就太過於學院派了，http狀態加名詞來命名，要知道實際開發中並不是只有CRUD，在某種特定只有增刪改查四種狀態的時候，確實是簡潔明瞭。但是當有其他功能時那該怎麼命名那，比如訂單操作，發貨、拆單、合單、確認發貨、收穫確認等等操作使用rest該怎麼處理 ？況且使用rest並不能提公升程式執行效率，反而使前後端聯調製的更加困難，得不償失。
乙個技術規範如果非常違反直覺並且實際生產中要為了這個規範妥協很多又沒有很大的好處，他就是有問題的。
11樓：長歌采薇
我個人最喜歡的是這種方式
/資源/動作，請求引數看情況選擇放在url還是body比如/article/add，/article/delete。
有一些屬於資源操作之外的操作，可以用/system/env, /system/login之類的
純粹的restful我覺得不夠友好，你說登陸這個動作是對應哪個資源的增刪改查呢，如果對應的是redis快取，如果以後更換了登陸session的儲存方式，那這個api改還是不改啊。
這還是僅限於新的專案，有些老專案，本來就設計的不是很合理，非要硬套restful真的是一地雞毛，我就見過把sql條件作為請求引數傳給後端的(當然後端有做一定的限制)。
12樓：大寬寬
一般的業務收益不大，麻煩卻很多。這些專案中應用Restful預期應該可以得到的風格統一，語義明確，方便理解等實際上並沒有那麼明顯。很多時候還會造成一些混亂和理解障礙。
WEB開發中，使用JSON-RPC好，還是RESTful API好？
反倒是，我非常想看到乙個非資源類業務（資源類指S3，OSS，CDN這種）用Restful成功的例子。
13樓：小馬
說下個人看法，之前按restful風格的介面寫過幾個版本的專案，實踐證明有些地方restful風格介面不理想，下面列舉幾個地方，實際應該更多
1.不是所有的介面都能很方便的抽象為資源，強制抽象得不償失，不如按業務去定義
2.引數分散到路徑、query、body三個地方，設計複雜，使用者用起來不方便，不喜歡，不買賬，不如全放body
3.內容返回整個資源造成頻寬浪費，高併發尤其明顯，不如僅返回需要的字段
4.請求方式根據動作設為post get delete patch put等，動詞可選擇性太少，不夠靈活，有些舊專案也不支援patch等，對接有困難，不如把動作直接放url裡
最終要用還是得改造很多地方的
14樓：ladjzero
RESTful 借用了 HTTP method 的語義來描述了業務上資源的 CURD 操作。RESTful 不能滿足所有的業務場景是很正常的，關鍵是前後端有沒有提出補充 RESTful 的語義？
我觀察到一些開發者並不關心介面的語義，不關心約定，試圖用文件來補充介面設計中方方面面的細節。是一種浪費「公共知識」的做法，反而會提高溝通的成本。
一些回答提到了防火牆的部署會影響 PUT DELETE 方法的使用。我認為這反而是 RESTful 的「優勢」，因為防火牆是可能通過 HTTP method 的語義來識別請求的意圖的，是一種在「公共知識」上應用的策略，大多數情況下是高效的。
15樓：犀利
我個人認為，restful就和xml一樣，雖然很強大，但學習成本較高。
不如全都POST，其他的細節去看介面說明，這樣基本上不管是前端後端還是給第三方客戶使用，大家都其樂融融。
簡單來說，就是經濟基礎決定上層建築。就好比漢語博大精深，但如果真的全世界統一語言，英語的適用性明顯強於漢語。
16樓：陳大俠
扯犢子的東西，簡單邏輯寫寫就得了，複雜邏輯還完全生搬硬套這個鬼東西就是自討苦吃，如果乙個東西查詢條件有幾十個，我看你怎麼get。
17樓：李巨集杰
除了其他人說的常見問題，你考慮過介面許可權管理和運維監控統計嗎/order/1 100次請求，響應時間為200ms/order/100 100次請求，響應時間為200ms這種統計資料有什麼意義嗎，當然，可以說我們可以二次彙總嘛那麼請問下面的
/a/1/b/2/c/3
你怎麼二次統計？運維人員還需要了解你所謂的rest介面？？
18樓：程式新視界
最主要的原因是RESTful並不能完全滿足各種業務場景。而且在語義表達上並不足夠清晰。
另外RESTful本身只是一種風格，並不完全是一種規範。
19樓：沙包妖夢
因為restful根本就不是規範，即使是，也根本不可能遵守。
restful這個詞從哪來都不明確，不知道是誰提的，更沒有什麼規範文件。
具體原因只要寫過哪怕乙個api介面也會明白。最經典的例子就是無法處理登入。
要是按restful的邏輯，放哪都不行，因為登入狀態本來就不是文章的一部分。。。
乙個API只要能用，就肯定不是restful
20樓：支浩宇
如果不按照規範寫，也能順利執行，說明這根本不是什麼規範。
什麼才是規範呢？你函式體裡面有個await，然後函式名前面不加async修飾，構建報錯了，說必須加async。這種強制性的，不遵守會導致程式罷工的東西，才是規範。
21樓：HylaruCoder
劍招是死的，人是活的。因為 RESTFul 語意比較不足, 業務一複雜就無法表達出足夠清晰的介面意圖
RESTful 有很多介面上最佳實踐，但生搬硬套就會使得介面比較詭異。
這裡只說生搬硬套 RESTFul 的帶來的缺點，並不是整體否定RESTFul。
比如，業務具備一定複雜性的時候，語義容易不明確。
預覽訂單和下單兩個介面，如果遵循如下的標準
介面路徑使用名詞而非動詞GET 不修改，POST/PUT/DELETE 修改狀態使用子字段來表述關係，查詢訂單 GET /shop/711/orders/
嚴格遵循 RESTful 的話，介面就會成這個樣子
GET /shops/1/order
PUT /shops/1/order
反正我是看不出來這是一坨啥玩意的，至於如果你硬性規範 PUT order 就是建立訂單，就會出現接下來兩個介面完全不知道該怎麼寫
支付訂單 （用 patch /shop/1/order)
取消訂單 （用 delete 方法，但業務本身並沒有 delete 這條訂單呀）
再次強調, 劍招是死的，人是活的。不嚴格遵循 RESTful 的時候可以這麼寫。
POST /preview_order
POST /cancel_order
這樣對於前後端來說, 見介面如見業務, 介面的語義性比較強, 可維護性就很高
更何況, 涉及訂單的介面累加起來幾十個(發貨、拆單、合單、確認發貨、收穫確認、發起退款等等), 硬用 RESTFul 就非常不容易想出清晰的介面名.至於第三點用子字段表述關係這點查詢訂單 GET /shop/711/orders
其實很多時候不如 GET /orders?shop_id=711
Flat is better than nested.
扁平優於巢狀
結論:因為 RESTFul 語意比較不足, 業務一複雜就無法表達出足夠清晰的介面意圖
補充: 並不是說 RestFul 徹徹底底的不好, 只是每個方案都有他的優缺點罷了.
Windows 為什麼會提供很多危險的介面？
熊起 原始套件字這個不算吧。檔案重定向之類更危險的。以前在書店裡看某本微軟的黑歷史，是這麼說的 微軟對不同層級的合作夥伴提供不同的API，這樣有一些功能強大的軟體就只有親密夥伴可以開發。這也保證了對生態圈的控制。當然隨著時間流逝，API流出就是另乙個問題了。 希望題主能在發問之前，先簡單的查一下什麼...
為什麼很多租房的都不要情侶？
不要情侶又能怎麼樣？單身的不是還可以瞬間變情侶嗎？所以說這種話一般是租客。我也是情侶和乙個單身妹子合租，我覺得可能對妹子不方便，所以一般除了必要吃飯，上廁所，洗漱，都呆在房間。相反的妹子是怎麼做的？乙個多星期後，就開始帶男生回來睡覺。我覺得睡睡也沒有什麼，畢竟妹子也有需求嘛。關鍵是這個妹子半夜3，4...
為什麼很多web專案還是使用 px，而不是 rem？
Tux ZZ 我的實踐中大部分元素用in，少量細小元素用px。因為in單位導致的非整數畫素的問題，雖然高分屏上一般不是問題，但是低分屏 細線條就是地獄了。所以用in這種物理尺寸來說更加直觀，px這種邏輯單位方便控制一些細小元素的尺寸。我知道目前裝置上的px全是邏輯畫素，然而邏輯畫素縮放比例參差不齊，...