New Post has been published on Mocco
New Post has been published on http://mocco.sk/a-look-at-the-wordpress-http-api-a-brief-survey-of-wp_remote_post/
A Look at the WordPress HTTP API: A Brief Survey of 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:
A practical example thereof
How to handle the response
And understanding the arguments for the function
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: wp_remote_post.
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.
Remote Requests: A Refresh
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.
Honestly, 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.
GET requests are typically used toĀ retrieveĀ information from the server, thus a response is expected
POST requests 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.
A Summary of How Requests Are Made
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_contents accepts 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.
cURL is 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, file_get_contents or cURL.
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.
How POST Requests Are Made in WordPress
As mentioned, the notes above are far more closely related to PHP, so letās a take a look at POST requests 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 wp_remote_post.
The function accepts two arguments:
The URL to which the request will be made
An array of arguments that help to tailor the request to the server.
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:
method refers to which method is being used for the request. Weāre obviously using POST given the nature of our API method.
timeout is 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.
redirection sounds 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-agent allows 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.
blocking in 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.
compress was 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.
decompress is 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.
sslverify was 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!
Other parts in this series:A Look at the WordPress HTTP API: wp_remote_get ā the Arguments
Check out the original source here.