New Post has been published on Mocco
New Post has been published on http://mocco.sk/a-look-at-the-wordpress-http-api-a-review/
A Look at the WordPress HTTP API: A Review
One of the challenges that comes with writing a series about an API – or even part of an API – is that it’s hard to cover every aspect of said API without spending too much time diving deep into one part and simultaneously trying not to simply skim across the top of each API without giving enough practical information.
Case in point: Throughout the last series, we’ve been taking a look at the WordPress HTTP API. Specifically, we’ve covered wp_remote_get and wp_remote_post, and we’ve done some relatively extensive work with both functions including building example projects.
The thing is, there’s still a lot of ground that could be covered in the WordPress HTTP API. In the future, we may do an advanced series on more aspects of the API, but for now, let’s review everything we’ve covered in this series.
But First, Why a Summary?
Writing a relatively lengthy series about a couple of functions can cover a lot of ground. The problem with doing this is that if at any time in the future you need to refer to one part, you may not recall exactly where the information was located.
Or, perhaps worse, you may have to trudge through a significant amount of information in order to find the one aspect that you need to keep making progress on your work.
And sure, you can always refer to the series index, but in order to give a “quick guide” of sorts, I thought it may be useful to summarize the articles, the functions, and high-level notes regarding the segment of the API that we covered just in case you need a reference for your work.
Of course, note that you can always view the series in its entirety on the series listing page.
Remote Requests
Before we review each of the functions, remember that a remote request can be defined as the process by which one server makes a request to another server.
Generally speaking, one server may simply send data to the other server which will then do something with it (be it save the data, process the data, and so on), and it may optionally send a response back.
At a high-level, that’s a remote request. For more information about this particular idea, be sure to check out this post.
wp_remote_get
wp_remote_get is a function that’s a part of the WordPress HTTP API that’s responsible for making GET requests.
The function accepts:
A URL to which the request is being made
The array of arguments to send along with the request
If you’re primarily responsible for retrieving information from the server, then this is the function that you will want to use.
Secondly, if you need more than a URL or more control over the request that’s being sent, then you can review this article to look at all of the arguments that it accepts.
How Does This Work?
Next in the series, we built an actual plugin that would leverage wp_remote_get in order for us to retrieve the number of followers for a given Twitter account, as well as the last tweet sent from said Twitter account.
The primary purpose of this article and this demo was to give a practical example of how to use wp_remote_get in a “real world” setting. For the full source code for the working demo, be sure to review the associated article.
What’s Being Returned?
Because wp_remote_get is focused on retrieving information, it only makes sense that we’d expect a response, right? In the final article covering wp_remote_get, we looked at what exactly is returned from the server and how WordPress formats it for our use.
If, during the course of your work, you have a difficult time deciphering exactly what it is that is coming back from the server (or why it’s not working as expected), then this is the article you should review.
wp_remote_post
Just as wp_remote_get is responsible for making GET requests, wp_remote_post is responsible for making POST requests.
Just as with the wp_remote_get, wp_remote_post accepts the same arguments:
The URL to which the request is being made
An array of arguments that help tailor the request to the server
But there’s a fundamental difference in the purpose of this function and the prior one that’s discussed. The difference is what happens when the request is completed.
Just as wp_remote_get is primarily used to retrieve data, wp_remote_post is used to send data across the wire to be processed – a response may never be sent back.
For the initial survey of this particular function – what it accepts including the advanced list of arguments – review this article.
How Does This Work?
Just as we did with wp_remote_get, we created a plugin to demonstrate how wp_remote_post works within the larger context of a WordPress theme.
Though the plugin is on GitHub for reference, we walk through the entire first version of the plugin in the following article. Specifically, we cover how to make the request to a script responsible for receiving $_POST data and then how it can format and return a response to the caller.
What’s Being Returned?
In the final article in the series, we completed the plugin by using LESS to give the plugin a slightly nicer look and feel, and we rounded out the plugin so that it actually saves some of the response data to the database just to give an idea as to how this can be achieved.
Conclusion
Summary posts are new territory – for me, at least – as I’ve historically let my series’ stand on their own, but I thought that this would be a nice reference to provide considering we covered so much ground in the series.
To reiterate:
With that said, let me know if you prefer summary posts or not. As I mentioned, this is something that I don’t typically do, but if it helps provide a point of reference for you guys, then I’m happy to continue doing them for future series’.
Other parts in this series:A Look at the WordPress HTTP API: Saving Data From wp_remote_post
Check out the original source here.