探索 WordPress HTTP API：了解 wp_remote_get 及其回應

在本系列中，我們研究了 wp_remote_get WordPress HTTP API 函數，以了解它的工作原理、如何使用它以及它接受的可選參數。

從這裡，我們可以編寫詳細的請求；然而，這只是一半 - 還有回應。

在第二篇文章中，我們了解了基本回應是什麼樣子、如何評估它以及如何在螢幕上顯示它，但我們實際上並沒有詳細討論回應。 p>

如果您希望編寫更高級的請求並編寫更多的防禦性程式碼，那麼了解作為回應發送的資料非常重要。在最後一篇文章中，我們將做到這一點。

---

查看回應

首先，理解我所說的編寫防禦性程式碼的含義很重要：在編寫軟體時，我們經常必須處理使用者可能做錯事、輸入可能設定不正確或資料可能被檢索或接收的情況- 例如在響應的情況下- 不正確。

為此，我們針對這些場景進行防禦性編碼，以便我們的軟體在用戶使用時不會完全崩潰或崩潰。相反，它會優雅地失敗並繼續運行。

透過了解函數到底接收到什麼來回應其請求，我們知道要查找哪些數據，然後當它沒有按我們預期返回時如何優雅地處理這種情況。

回應範例

為了為預期做好準備，讓我們看一下範例回應。假設您要向 URL 發出 GET 請求，該請求將向您傳回一段簡單的文字。

一般來說，您可能會提出更複雜的請求，其中回應可能是 XML 或 JSON 或其他內容；但是，所有這些資訊都會設定在回應數組的 body 索引中。因此，如果您了解會發生什麼，那麼您就知道如何處理它。

話雖如此，這是您期望從對網域的簡單請求收到的回應，該請求只會傳回純文字。

Array
(
    [headers] => Array (
            [date]          => Thu, 30 Sep 2010 15:16:36 GMT
            [server]        => Apache
            [x-powered-by]  => PHP/5.3.3
            [x-server]      => 10.90.6.243
            [expires]       => Thu, 30 Sep 2010 03:16:36 GMT
            [cache-control] => Array (
                    [0] => no-store, no-cache, must-revalidate
                    [1] => post-check=0, pre-check=0
            )
            [vary]           => Accept-Encoding
            [content-length] => 1641
            [connection]     => close
            [content-type]   => application/php
        )
    [body]     => 'A simple bit of text.'
    [response] => Array (
				    [code] => 200
				    [message] => OK
			   )
    [cookies] => Array()
)

只不過是一個陣列（或實際上是一個陣列的陣列）。沒什麼太壞的，對吧？

讓我們詳細查看每個回應元素。

標題

從上面的回應可以看出，標頭實際上是由另一個包含其他資訊的陣列組成的。

在查看上面的每個資訊之前，先了解標頭到底是什麼非常重要。簡而言之，標頭提供有關客戶端和伺服器之間存在的請求/回應通訊的資訊。

可以發回各種各樣的標頭（其中許多超出了本文的範圍），但所有這些標頭不僅可以幫助我們獲取有關請求的信息，還可以幫助我們獲取有關請求的伺服器的信息。我們正在溝通。

話雖如此，讓我們詳細看看每個標頭元素。

日期

顯然，這是一個非常容易理解的元素：簡單地說，這是訊息發送的日期和時間。它顯然包括格林威治標準時間的星期、日期和時間，格林威治標準時間是全球時間標準。

伺服器

伺服器元素指的是伺服器運行的軟體類型。通常，您可能會看到 Apache；然而，現在還有其他可用的伺服器應用程序，例如 IIS 和即將推出的 nginx。

X-Powered-By

X-Powered-By 是指為通訊事務提供支援的伺服器軟體。在我們的例子中，我們看到 PHP，這只意味著我們的請求被傳送到執行 Apache 和 PHP 的伺服器。

但情況可能並不總是如此。

例如，您最終可能會與執行 nginx 和 Python 的伺服器或執行 Ruby on Rails 的其他類型的伺服器軟體進行通訊。

X-伺服器

此特定回應元素指的是請求傳送到的伺服器的 IP 位址。我很少需要知道這些特定的資訊；但是，如果您最終得到意外回應，儘管所有其他資訊看起來都按順序進行，那麼了解伺服器的IP 是否與您期望的請求發送到的網域相符可能會有所幫助。

過期

每當發出請求並發送回應時，可以說該回應都有生命週期。

更具體地說，回應在一段時間後將被視為「過時」。顯然，回應被視為過時的時間就是回應被認為已過期的時間。

回應被視為非過時的時間取決於伺服器的配置，但時間戳與請求日期的格式相同。

快取控制

快取控制是指網路瀏覽器（或用戶端和伺服器之間存在的其他快取機制）可能或可能無法使用第一個回應作為未來請求的回應的概念。 p>

例如，如果伺服器回應no-cache，則表示請求機器的瀏覽器、伺服器或其他代理軟體或快取機制必須將每個回應視為新回應。另一方面，如果 no-cache 未指定，則第一個回應可能是您能夠獲得的唯一回應（至少在快取設定為過期之前） .

這顯然由兩個索引組成：

1. 第一個索引包含no-cache是否已設定
2. 第二個索引包含資料是否已快取的資訊。簡單地說，如果 post-check 和 pre-check 間隔已過期，則將請求更新版本的資料；否則，將檢索快取的版本。

快取的這個特定方面超出了本系列的範圍，因為可以編寫和解釋更多內容；但是，上面的定義應該足以幫助解釋您所看到的標頭。

變化

此標頭值與 Cache-Control 標頭類似，它告訴請求伺服器如何處理類似的後續請求。

一般來說，這將指示伺服器是否可以使用快取回應，或者必須檢索新值。這是另一個可能變得過於複雜的元素，但為了嘗試將解釋提煉為我們正在討論的範圍更廣的內容，變化標頭元素還可以向伺服器指示伺服器所需的各種內容類型。 客戶端可以處理。

因此，在上面的範例中，我們指示伺服器我們的客戶端能夠處理編碼訊息。

內容長度

內容長度是一個簡單的概念，有一個陷阱：首先，它簡單地定義了回應正文的長度。

問題是，它以 8 位元位元組進行。這意味著回應不是以千位元組、兆位元組或我們通常看到的任何形式的資料提供的。

為此，如果您希望收集有關返回資料的更豐富的信息，則可能需要執行一些轉換。

連接

連線值指定請求瀏覽器首選的連線類型。上面，我們看到該值被定義為“close”，這意味著一旦發送回應，就可以關閉連線。

但是，還有其他選擇。例如，您可能會收到“keep-alive”，顯然，它希望將連接保持活動一段時間。

這又是一個需要單獨的文章來充分討論的例子；但是，這確實可以深入了解伺服器喜歡的連接類型，這可以幫助您建立未來的請求。

內容類型

這實際上只與 POST 和 PUSH 請求相關。簡而言之，這定義了請求的正文類型。

這可能會因發送的資料而異。有時它可能是一個編碼的 URL，有時它可能是 PHP，有時它可能是其他東西。無論如何，這有助於確保我們可以檢查內容中傳回的資料是否符合我們根據請求所期望的資料。

正文

body元素實際上包含了從伺服器返回的資訊。

在前兩篇文章的範例中，我們收到了來自 Twitter 的 JSON 字串。在上面的範例中，我們收到一個簡單的文字字串。最終，響應可能會以某種形式的二進位資料返回，需要一定程度的反序列化。

無論如何，身為請求的實現者，我們有責任了解如何在向使用者顯示回應之前正確解碼回應。

響應

回應其實是指從伺服器傳回請求客戶端的HTTP回應碼。如果您不熟悉 HTTP 狀態代碼，那麼我建議您查看 HTTPStat.us，以獲得非常好的參考。

簡而言之，回應由數字代碼和基於文字的訊息組成，用於指示請求的結果。

程式碼與訊息

在上面的範例中，您可以看到我們收到了「200」狀態代碼和「OK」訊息。代碼和訊息對應始終彼此同步。

這意味著，如果您收到“403”，那麼您還應該收到“禁止”訊息，或者如果您收到“404”，那麼您應該收到“未找到”訊息。

就我個人而言，我發現這些特定值對於診斷我提出的請求是否出現問題非常重要。

Cookie

最後，cookie 陣列指的是基於目前用戶端和進行通訊的伺服器之間存在的 cookie 透過網路傳送的任何資訊。

根據您要求的性質，這可能為空，也可能不為空 - 這根據具體情況變化太大，無法提供任何明確的指導。簡而言之，如果兩個連線之間沒有建立 cookie，那麼該連線很可能始終為空；否則，組成 cookie 陣列的資料將專門基於兩個服務之間存在的 cookie。

---

結論

總體而言，資料量相當大，並且根據您要求接收的內容以及伺服器的回應，資料將因請求而異；然而，問題是您現在知道會發生什麼以及如何正確處理所有情況。

如果你的工作變得更糟，你可以隨時使用調試器或簡單地放置一些調試語句，例如print_r 或var_dump 來查看伺服器返回的內容，以便你可以優雅地處理錯誤。

稍後，我們將重新造訪 WordPress HTTP API 以檢查其他方法，例如 wp_remote_post 和 wp_remote_request，以便我們全面了解 HTTP API。

到那時，本系列將有望為您提供對wp_remote_get 的盡可能深入的介紹，不僅可以幫助您改進工作，還可以激發您對遠端請求方面還有什麼可能的好奇心。

以上是探索 WordPress HTTP API：了解 wp_remote_get 及其回應的詳細內容。更多資訊請關注PHP中文網其他相關文章！