超文本傳輸??協議 - HTTP協議 - 定義了幾種方法(稱為“動詞”)，指示要對資源執行的所需操作。資源由 URI(統一資源標識符)指定，更常見的是 URL。該資源可能是預先存在的數據或動態生成的數據，這取決于服務器的實現。服務器可以配置為支持任何方法組合。最常見的是：GET、POST、PUT 和 DELETE，但還有其他幾種。可以定義的方法數量沒有限制，這允許在不破壞現有基礎架構的情況下指定未來的方法。

冪等性的概念與此討論相關。如果某件事是冪等的，那么無論你做多少次，結果總是一樣的。一個很簡單的例子來自數學：乘以1;無論您將任何數字乘以 1 多少次，結果將始終相同：原始數字。

SOAP API 在通過 HTTP 發送時，只能使用 POST 動詞，具體的操作取決于被調用的 SOAP 方法。REST，作為一種架構風格而非標準，充分利用了所有可用的動詞。對于每個動詞應該或不應該做什么沒有明確的答案。在測試 RESTful API 時，您可以使用以下最佳實踐作為起點，但請咨詢您的內部架構師或開發負責人，以了解您的項目究竟遵循什么。

在這里討論的四種方法中，POST 是唯一被假定為非冪等的方法。這是在應用程序中創建新對象時的首選方法，例如創建新訂單。每個 POST 方法調用都應該導致在數據庫中創建(或可能刪除)一個新對象。

使用 POST 方法實現整個 API 中的每一個調用并不少見，尤其是對于遺留應用程序。這是架構問題和缺乏遠見的指標。如果還存在資源層次結構問題，未來的增強將很困難。作為測試人員，在這種情況下您應該特別謹慎，并在進行估算時考慮額外的測試時間。

PUT 方法應該是冪等的。“應該”一詞表示服務器能夠以不同的方式實現此方法。測試人員應該將這樣的實現標記為不一致。

PUT 仍然可以用于創建對象，盡管由于它是冪等的，重復執行相同的請求將具有與第一次相同的最終結果。例如，無論您發送多少次創建相同客戶 ID 的請求，它都應該只在數據庫中創建一次。

DELETE方法是冪等的;多個請求應該只導致一件事被刪除。例如，考慮上面的場景，多個 POST 請求被發送到服務器以獲得新訂單，從而導致同一產品的多個訂單。一個 DELETE 請求應該接受一個唯一標識符以從訂單中只刪除一個產品，因此發送相同的 DELETE 請求將導致正確的冪等操作：產品的一個實例。

如果 DELETE 請求接受產品名稱，多次發送請求最終會從訂單中刪除所有產品，從而導致此方法的非冪等實現。同樣，作為測試人員，這種情況應該引起開發團隊的注意。這種“多次刪除”功能的更正確實現是結合正確制作的 URL 的 POST 操作，例如：/{order_number}/{product_name}/刪除

GET 操作通常僅用于從系統中檢索信息。沒有添加或更改任何內容，因此它不僅僅是冪等的，它實際上是無效的——它對數據絕對沒有副作用，除了可能的日志記錄。

概括

正如我們提到的，在使用 REST 時可以有“其他動詞”。在這種情況下，需要記住以下幾點：

由于 REST 沒有標準，因此請確保從事產品工作的每個人都使用相同的定義。這應該由您團隊的開發負責人設置。

由于某些動詞不是冪等的，因此每個人，尤其是使用公共 API 的消費者，在使用它們時都期望得到相同的結果，這一點至關重要。

驗證是否使用了正確的動詞。由于某些動詞可以達到相同的結果，因此請確保使用正確的動詞。從功能和一致性的角度來看。

以上就是關于“了解rest請求方法”的介紹，如果大家想了解更多相關知識，可以關注一下動力節點的Java在線學習，里面的課程內容從入門到精通，細致全面，很適合沒有基礎的小伙伴學習，希望對大家能夠有所幫助。