In this first series of the WordPress HTTP API, we learned about wp_remote_get. Specifically, we looked at the following aspects of the API:
We will continue our series of articles about the WordPress HTTP API, but we will turn our attention to the second method of the API: wp_remote_post.
In the next set of articles we will survey this function to understand what this function provides and why it is useful, practical examples of how to implement it into our work, and how to understand and come from this function the response to.
With that said, let’s begin our investigation of this function.
If you haven't followed along so far, I highly recommend checking out the first article in this series to at least understand the basics of how GET requests work.
Honestly, POST requests are not that different. Just as a GET request is typically used to retrieve information from a server, a POST request is typically used to send a message to a server.
But here's the thing: both protocols are capable of sending and receiving data, but here's a general rule of thumb on how I typically handle GET and POST requests.
GET The request is typically used to retrieve information from the server and therefore requires a response POST request is typically used to send information to the server , and although a response may not be received, it is always good to know if the response was received and processed correctly by the server In the remaining articles in this part of the series, we will see how to handle both situations - that is, how to handle the situation where no response is given and how to handle the situation where a response is given.
Now, as far as server-level requests are concerned (especially in PHP), they are usually issued based on the following two functions (unless you are using a third-party library that is beyond the scope of this series).
While we covered these in more detail in our first article, I'll summarize them here.
file_get_contents Accepts a URL as a parameter and will return the requested data or false on failure. This is a relatively common way to retrieve data for remote requests. cURL is a complete library (rather than a function) that provides developers with complete configuration options to adjust to suit their needs. There is a lot to learn about this library. If you are an advanced developer, definitely check out cURL. In most cases, it's easy to figure out how to make the request, but the extent to which you adjust how the request is made depends entirely on the options you choose to use - that is, file_get_contents or cURL.
Of course, this is more of the PHP way of doing requests, and while we may implement this in some jobs depending on the nature of the project, this doesn't necessarily cover the WordPress way.
In fact, the above content is a brief review based on the previous content. Nonetheless, it is important to understand where we come from, what we can do, and where we are going.
How to make a POST request in WordPress
POST request in the context of WordPress.
So, just like we looked at the WordPress Coding Standards to review best practices for writing WordPress-based code, we will now look at the APIs available for writing
POST requests using best practices.
wp_remote_post.
method refers to which method is requested. Given the nature of our API methods, we're obviously using POST. timeout is how long you are willing to wait for a request to be processed before giving up. The default value is five seconds, but this value can be reduced or increased depending on the nature of the application. redirection Sounds like the URL you will be redirected to after the request completes, right? Instead, it is the unit of time (in seconds) to wait for a redirect before giving up the request. user-agent Allows us to control the user agent sent with the request. Typically, this is WordPress and the version number, but it's obviously customizable. blocking In short, if set to true then the script will continue executing until the server returns something; otherwise, the script will continue running without blocking the rest of the application. Of course, this comes at the cost of possibly never getting a response, but depending on the conditions you're building in, this might be fine. compress was introduced in WordPress 2.6 and allows you to send the request body in a compressed format. This will be beyond the scope of our future articles. decompress Similar to compress, except on our side - 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 where you need to check whether an SSL certificate is valid. If not, the request is denied; otherwise, you're good to go. This option is also outside the scope of this set of articles. Obviously, there is a lot available. Over the next few articles I hope to look at some of this in more detail, but first let's look at a very simple, practical example using API functions.
POST RequestThings should be clear by now, right? Using wp_remote_post should be just as easy as using wp_remote_get, so starting with the next post, we'll do that.
Before that, please make sure you have read all the articles so far, and please leave any comments and/or questions about this specific post in the comments.
Next, let’s get to work!
The above is the detailed content of Explore the WordPress HTTP API: wp_remote_post Overview. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
