本文是《WordPress HTTP API 指南》系列教程的第 5 部分，该系列共包含以下 8 个部分：
在 WordPress HTTP API 指南这个系列的上半部分，我们讲解了 wp_remote_get，具体说来有如下几个方面：
我们继续该系列的讲解，不过这次要了解的是这个 HTTP API 的第二种方法：wp_remote_post。
In the first series on the WordPress HTTP API, we took a look at
wp_remote_get. Specifically, we took a look at the following aspects of the API:
We’re going to continue the series on the WordPress HTTP API, but we’re going to turn our attention to a second method of the API:
Throughout the next set of articles, we’re going to take a survey of the function to understand what the function offers and why it’s useful, a practical example of how to implement it into our work, as well as how to understand the functions and the response that comes from the function.
With that said, let’s begin our survey of the function.
If you’ve not been following along thus far, I highly recommend checking out the very first post in the series to at least understand the basics of how
GET requests work.
POST requests aren’t all that different. Just as
GET requests are typically used to retrieve information from the server,
POST requests are usually meant to send messages to the server.
But here’s the thing: both protocols are capable of sending data and receiving data, but here’s a general rule of thumb for how I typically approach GET and POST requests.
GETrequests are typically used to retrieve information from the server, thus a response is expected
POSTrequests are typically used to send information to the server, and although a response may not be expected, it’s always nice to know if the server received and processed the response properly or not
Throughout the rest of the articles in this part of the series, we’ll be taking a look at how to handle both cases – that is, how to handle when no response is given and how to handle when a response is given.
Now, as far as requests are concerned at the server-level – specifically in PHP – they usually are made given the following two functions (unless you’re using a third-party library which is out of the scope of this series).
Though we’ve covered these in greater detail in the first post, I’ll be summarizing them here.
file_get_contentsaccepts a URL as a parameter and will return the data that’s requested or a false on failure. It’s a relatively common way to retrieve data for remote requests.
cURLis an entire library (rather than function) that provides full configuration options for developers to tweak to suit their needs. There’s much to learn about this library. If you’re an advanced developer, definitely check out cURL.
For the most part, understanding how requests are made is easy enough, but the degree to which you tweak how the requests are made is completely contingent on which option you opt to use – that is,
Of course, this is more of the PHP-way of performing requests and although we may be implementing this in some of our work depending on the nature of the project, this does not necessarily cover the WordPress-way of doing it.
In fact, the above is a short refresher based on previous content. Nonetheless, it’s important to understand where we’re coming from, what’s available, and where we’re headed.
POSTRequests Are Made in WordPress
As mentioned, the notes above are far more closely related to PHP, so let’s a take a look at
POSTrequests within the context of WordPress.
And if you’re in the business of building projects for WordPress or products on top of WordPress, it’s important to understand the APIs that are available to make sure that you don’t lose some type of feature or functionality with an upgrade to the core WordPress Application.
So, just as we’ve looked at the WordPress Coding Standards to review the best practices for writing WordPress-based code, we’re now going to be looking at the APIs available for writing
POST requests using best practices.
To that end, enter
The function accepts two arguments:
Though the array of arguments are going to be somewhat outside of the scope of what we’re going to be doing in this series, it’s important to understand what’s available especially if you’re going to be doing more advanced work in the future:
methodrefers to which method is being used for the request. We’re obviously using
POSTgiven the nature of our API method.
timeoutis how long you are willing to wait for the request to process before giving up. The default value is five seconds, but this can be decreased or increased based on the nature of your application.
redirectionsounds like it’s the URL to which you’d be redirected after the request has completed, right? Instead, it’s a unit of time – in seconds – to wait on a redirection before giving up on the request.
user-agentallows us to control the user-agent that’s being sent along with the request. Usually, this is WordPress and the version number, but it’s obviously customizable.
blockingin short, if this is set to true then the script will continue to execute until something is returned from the server; otherwise, the script will continue operating without holding up the rest of your application. Granted, this comes at the expense of potentially never getting back a response, but depending on the conditions for which you’re building, this may be fine.
compresswas introduced in WordPress 2.6 and allows you to send the body of the request in a compressed format. This will be outside the scope of our future articles.
decompressis similar to compress except that it’s on our end – if compressed data is received, this will allow us to decompress the content before doing any further work or processing on it.
sslverifywas introduced in WordPress 2.8 and is useful for scenarios in which you need to check if an SSL certification is valid. If it’s not, then the request is denied; otherwise, you’re good to go. This option will also be outside the scope of this set of articles.
Obviously, there’s a lot of stuff that’s available. Over the next few articles, I hope to examine some of these in more detail, but first let’s take a look at a very simple, practical example of using the API function.
At this point, things should be clear enough, right? Using
wp_remote_post should be just as easy as using
wp_remote_get so starting in the next article, we’re going to be doing just that.
Until then, make sure you’ve reviewed all of the articles leading up to this point, and please leave any comments and/or questions to this particular post in the comments.
Next up, we’ll get to work!