拋棄restful風格API

拋棄restful風格API

相對于 直接只用一個post請求而言，restful缺陷，畫蛇添足的缺點太多了，我的個人第一直接感悟如下：

1. login 登陸 多資源一起操作，這個資源路徑應該如何寫；說白了，就是業務邏輯的動作方法，是很難以被抽象為資源的增刪改查；

   想用對一個資源的簡單CRUD的操作，也抽象出來 你真正想要的業務邏輯動作方法，我懷疑你腦袋進水了；一個業務邏輯方法往往是很多表的聯合查詢，聯合處理，才能得出一個業務邏輯；你非要用對一個資源的CRUD來抽象出來你實際想要的業務邏輯，就是說 明明很簡單的事，你要繞道地球幾圈來搞，這樣的垃圾人才真不少；

2. 把動作變成請求方法，要知道 RPC 或者函數棧世界里，程序的核心思想就是方法，方法就是對資源的動作，非要把動作和資源 強制分離開來，從 哲學上來說，完全脫褲子放屁，restful提出來 20么多年 火不了，是有原因的，菜鳥會人云亦云，大牛是不會這么搞的，我也沒有看到 大的平臺的接口是restful風格的，菜鳥太多；restful 從哲學理論上 就行不通，落地不了，我斷言以后10年也落地不了；始終是一些小項目 小范圍的菜鳥使用；

restful的缺陷 你自己去biying吧，我不贅述了：

以下是我問文心一言的：

restful風格不靈活，若一個接口 對多個資源進行操作 怎么寫路徑？

RESTful API 的設計原則鼓勵對單一資源進行操作，但有時候我們確實需要在一個接口中對多個資源進行操作。這種情況下，我們可以考慮以下幾種策略來設計路徑：

1. 使用復數資源名稱：
   如果操作涉及到同一類型的多個資源，可以使用復數形式的資源名稱來表示。例如，如果你想要同時操作多個訂單，可以使用 /orders/batch 或 /orders/multiple 這樣的路徑。

2. 使用查詢參數：
   通過查詢參數來指定需要操作的多個資源的ID。例如，/resources?ids=1,2,3，這樣服務器就知道需要對哪些資源進行操作。

3. 使用動作作為路徑的一部分：
   雖然這有點違背RESTful原則，但有時為了實用性，我們可以在路徑中包含動作，如 /resources/batch-update 或 /resources/multi-delete。

4. 使用POST請求體傳遞資源列表：
   通過POST請求，并在請求體中發送一個包含多個資源ID的列表或需要執行的操作細節。這樣，服務器可以根據請求體中的內容對多個資源執行相應的操作。

5. 創建專門的批量處理接口：
   可以設計一個專門的接口來處理批量操作，比如 /batch-operations，然后通過POST請求體來描述需要對哪些資源執行何種操作。

6. 使用任務或操作ID：
   如果批量操作是異步執行的，可以首先創建一個任務或操作，并返回一個操作ID。然后，客戶端可以使用這個ID來查詢操作狀態或結果，例如 /batch-tasks/{taskId}。

7. 混合使用：
   你也可以混合使用上述策略，比如通過POST請求體發送資源列表到 /resources/batch-update 路徑。

請注意，雖然這些方法可能不完全符合嚴格的RESTful原則，但在實際應用中，為了滿足業務需求，有時的確需要對這些原則進行一定的折衷。重要的是保持API的一致性、可預測性和易用性。

同時，對于批量操作，務必謹慎處理，因為它們可能會對系統造成較大的負載。在設計這樣的接口時，應該考慮到性能、安全和事務性等方面的問題。

restful 的缺陷？

RESTful風格的API設計雖然有其優點，但也存在一些缺陷。以下是對RESTful缺陷的清晰歸納：

1. 面向資源的設計限制：

   • RESTful API是面向資源的，這意味著所有操作都需要抽象為對某種資源的操作。在某些情況下，這可能會增加API設計的復雜性并降低直觀性。例如，登錄和登出操作在RESTful API中可能需要抽象為對“authentication”資源的操作，使用POST和DELETE方法來表示，這不如直接的方法調用直觀。

2. 部分字段查詢的困難：

   • 在RESTful API中，部分字段查詢可能不如非RESTful設計直觀。例如，按照狀態查詢用戶可能需要創建一個特定端點或使用查詢參數，這增加了API的復雜性和學習成本。

3. 監控和排障的困難：

   • RESTful API鼓勵使用路徑參數，這可能導致配置反向代理服務器（如Nginx）變得復雜。使用正則表達式來匹配路徑參數和指定HTTP方法可能增加了配置的復雜性。

4. 可讀性的降低：

   • 在RESTful API中，理解一個接口的含義需要結合HTTP方法和路徑，這可能會降低API的可讀性，尤其是對于不熟悉RESTful風格的開發人員。

5. 缺乏標準化：

   • RESTful API沒有一套統一的標準，導致不同的開發者和組織可能有不同的實現方式和規范。這種“模糊性”給開發和維護帶來了挑戰。

6. 安全性問題：

   • 由于RESTful API基于HTTP協議，它可能面臨一些安全性問題，如跨站腳本攻擊（XSS）和跨站請求偽造（CSRF）。

7. 大量數據傳輸問題：

   • 使用HTTP協議進行通信的RESTful API在傳輸大量數據時可能會出現性能瓶頸。

8. 版本控制問題：

   • 沒有統一的標準也導致了版本控制上的困難，可能會使得API的升級和維護變得復雜。

綜上所述，RESTful風格雖然在一些方面有其優勢，但也存在不少缺陷，需要在設計和使用時進行綜合考慮。