我正在開發一個報告系統，該系統通過網絡服務調用為圖表數據提供服務。在某些情況下完成搜索，在其他情況下完成配置更新。代碼的 UI 端恰好是 Angular，后端是 Java，Oracle 作為持久性存儲。有趣的是，除了普通的 JDBC 之外，沒有使用任何 Java 持久性框架。但是，我的問題至少與這些事情無關。幾乎所有對資源之類的請求都是通過 POST 請求發出的。因此，獲取特定報告的數據是一個 POST 請求，狀態返回在基于 JSON 的響應中（OK 表示有效，ERROR 表示無效）。這不是我對 REST 標準的理解。我原以為開發人員應該對資源發出 GET 請求，通過查詢字符串參數或請求標頭提供輸入。改變狀態或資源的調用將通過 POST 或 PUT 進行。不遵循這些標準而只是采用我們自己的范例并發布所有內容的后果是什么？
1 回答
阿波羅的戰車
TA貢獻1862條經驗 獲得超6個贊
不遵循這些標準而只是采用我們自己的范例并發布所有內容的后果是什么？
您放棄的是通用組件在了解請求是安全的情況下可以提供的優勢。
例如，Web 瀏覽器可以通過主動獲取您可能需要的資源表示來優化用戶體驗。
同樣，在不穩定的網絡上，如果響應丟失，通用組件可以知道重試請求——因為請求的語義保證這樣做沒有風險。
此外，如果一切都是 POST，那么您將不斷從 HTTP 感知緩存中逐出表示。 緩存約束在 REST 架構風格中很重要——事實上我們可以從網絡下載一次表示然后重新使用它，這是擴展網絡的關鍵部分。
HTTP 規范的一個有趣的角落是，它304 Not Modified不是POST 請求的允許響應代碼之一。沒有條件 GET 的模擬。
當一切正常時POST，您正在采用一個應用程序協議并將其變成一個啞消息隧道，僅向通用組件提供對正在發生的事情的最弱可能的語義描述。
這并不一定意味著對所有內容都使用 POST 是錯誤的。SOAP 走的是這條路，而 GraphQL 似乎也在走這條路。HTTP 沒有針對遠程過程調用風格進行優化，但它是有能力的。
添加回答
舉報
0/150
提交
取消