探索 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中文网其他相关文章！