單一 API 端點的優缺點

Question

我正在創建 API 並試圖找出計划好的方法。
該 API 不是公開的，它將被我構建的 SPA 和移動應用程序使用。
所以我在考慮類似 GraphQL 的設計，但沒有發布 json 和常規的 HTTP 方法。 對於 GET 方法，類似這樣的事情：

示例 1 - 獲取具有特定字段的用戶（_join 表示 sql table join），排序和限制：
api.com?table=users&displayFields=id,name,email,address,tel,country_join&orderBy=asc&orderColumn=name&offset=0&limit=10

示例 2 - 基於所有字段、排序和限制的搜索參數獲取用戶：
api.com?table=users&search=John&searchFields=name,email&orderBy=asc&orderColumn=name&offset=0&limit=10

我認為這很糟糕，因為 REST 是標准的，否則我會看到更多這種方法的例子。
但為什么這很糟糕？ 對我來說，它似乎更容易開發和使用更靈活。
我提供的示例的適當 REST API 是否更易於實現、更安全、更易於使用或緩存？

Answer 1

我看到將變量放入 url 與請求正文之間的主要區別是：

• 數據的長度作為 url 長度是有限的，而請求體不是
• 要在 url 中轉義的特殊字符，這可能導致 url 長而不清楚

這是支持請求正文中數據的 2 個優點，但我同意 url 中的數據更易於測試和使用，因為您不需要像 curl 或郵遞員這樣的 http 客戶端工具來驗證您的端點。

然而，如果你想完全實現它，REST 有更嚴格的約定：

• 使用正確的 http 請求（get、post、patch、delete 和 put）在單個端點上實現 crud 操作
• 結果返回正確的http代碼
• 使用標准數據格式進行輸入和輸出（json 或 XML）

為了更好地實現系統之間的互操作性，建議遵守 REST 和微服務設計模式。

對於小型應用程序，我們可以遵循一些捷徑而不完全遵守。 到目前為止，我已經集成了幾個服務，每次我都可以告訴你，沒有一個服務實現了標准的 REST :-)