探索 WordPress HTTP API：wp_remote_post 概述-php教程-PHP中文網

在 WordPress HTTP API 的第一個系列中，我們了解了 wp_remote_get。具體來說，我們研究了 API 的以下幾個方面：

我們將繼續有關 WordPress HTTP API 的系列文章，但我們將把注意力轉向 API 的第二種方法：wp_remote_post。

在下一組文章中，我們將對該函數進行調查，以了解該函數提供什麼以及它為何有用，如何將其實現到我們的工作中的實際示例，以及如何理解它函數以及來自該函數的響應。

話雖如此，讓我們開始對該函數的調查。

遠端請求：刷新

如果您到目前為止還沒有跟進，我強烈建議您查看本系列中的第一篇文章，至少了解 GET 請求如何工作的基礎知識。

老實說，POST 請求並沒有那麼不同。如 GET 請求通常用於從伺服器檢索資訊一樣，POST 請求通常用於向伺服器發送訊息。

探索 WordPress HTTP API：wp_remote_post 概述

#但事情是這樣的：兩種協定都能夠發送資料和接收數據，但這裡有一個關於我通常如何處理 GET 和 POST 請求的一般經驗法則。

在本系列這一部分的其餘文章中，我們將了解如何處理這兩種情況 - 即，如何處理沒有給出回應的情況以及如何處理有回應的情況已給出。

現在，就伺服器層級的請求而言（特別是在 PHP 中），它們通常是根據以下兩個函數發出的（除非您使用的第三方程式庫超出了本系列的範圍））。

雖然我們在第一篇文章中更詳細地介紹了這些內容，但我將在這裡對其進行總結。

file_get_contents 接受 URL 作為參數，並將傳回請求的資料或失敗時傳回 false。這是一種為遠端請求檢索資料的相對常見的方法。
cURL 是一個完整的函式庫（而不是函數），它為開發人員提供完整的配置選項，以便進行調整以滿足他們的需求。關於這個庫有很多東西值得學習。如果您是高級開發人員，一定要看看 cURL。

在大多數情況下，了解如何提出請求是很容易的，但是您對請求的提出方式進行調整的程度完全取決於您選擇使用的選項- 也就是說， file_get_contents 或cURL。

當然，這更多的是執行請求的 PHP 方式，儘管我們可能會根據專案的性質在某些工作中實現這一點，但這並不一定涵蓋 WordPress 的方式。

事實上，以上內容是在先前內容的基礎上的一個簡短的回顧。儘管如此，了解我們從哪裡來、可以做什麼以及我們要去哪裡非常重要。

如上所述，上面的註解與 PHP 的關係更為密切，因此讓我們來看看 WordPress 上下文中的 POST 請求。

如果您從事為 WordPress 建立專案或在 WordPress 上建立產品的業務，那麼了解可用的 API 非常重要，以確保您不會因升級而丟失某些類型的特性或功能到核心 WordPress 應用程式。

因此，就像我們查看 WordPress 編碼標準來回顧編寫基於 WordPress 的程式碼的最佳實踐一樣，我們現在將查看可用於使用最佳實踐編寫 POST 請求的 API。

為此，請輸入 wp_remote_post。

此函數接受兩個參數：

雖然參數數組在某種程度上超出了我們在本系列中要做的事情的範圍，但了解可用的內容非常重要，特別是如果您要在本系列中做更高級的工作未來：

method 指的是請求使用哪個方法。考慮到我們 API 方法的性質，我們顯然正在使用 POST。
timeout 是您在放棄之前願意等待請求處理的時間。預設值為五秒，但可以根據應用程式的性質減少或增加該值。
redirection 聽起來像是要求完成後您將被重定向到的 URL，對嗎？相反，它是放棄請求之前等待重定向的時間單位（以秒為單位）。
user-agent 讓我們可以控制隨請求一起傳送的使用者代理程式。通常，這是 WordPress 和版本號，但它顯然是可自訂的。
blocking 簡而言之，如果設定為 true 那麼腳本將繼續執行，直到伺服器傳回某些內容；否則，腳本將繼續運行，而不會阻止應用程式的其餘部分。當然，這是以可能永遠不會得到回應為代價的，但根據您建立的條件，這可能沒問題。
compress 是在 WordPress 2.6 中引入的，允許您以壓縮格式發送請求正文。這將超出我們未來文章的範圍。
decompress 與 compress 類似，只不過它是在我們這邊 - 如果收到壓縮數據，這將允許我們在對其進行任何進一步的工作或處理之前解壓縮內容。
sslverify 是在 WordPress 2.8 中引入的，對於需要檢查 SSL 憑證是否有效的場景非常有用。如果不是，則請求被拒絕；否則，你就可以走了。此選項也不屬於這組文章的範圍。