Creative Coding

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 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.


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.


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'.

Related Posts
  • Code
    Creative Coding
    A Look at the WordPress HTTP API: Saving Data From wp_remote_postDiagram http api
    In the previous post in the series, we began working on a small plugin that provided a practical example of wp_remote_post. The thing is, the example was incomplete. Sure, it's nice to see how to make a call using the function and even how to setup a script responsible for receiving the data and returning the data, but it's of little use unless we do anything with it. In this final article in the series, we're going to revisit the plugin that we started with the last article and begin improving it a bit. Specifically, we will... Review what we've done Begin making some changes to the work that we created in the last article Style the presentation with LESS in order to keep some of our newer skills updated Review the arguments accepted by both wp_remote_get and wp_remote_post Finally, all of the work accomplished in this article will be available on GitHub and linked in the conclusion of the article. But before that, let's go ahead and get started.Read More…
  • Code
    Creative Coding
    A Look at the WordPress HTTP API: A Practical Example of wp_remote_postDiagram http api
    In the previous article, we reviewed the previous articles regarding GET requests, the native PHP facilities for making requests, and reviewed WordPress wp_remote_post API function along with the arguments that it offers. In this article, we're going to make use of wp_remote_post such that we're actually able to see it in action. Remember that this - like wp_remote_post - is part of the HTTP API of which there are other functions worth reviewing. But, for now, we're going to put wp_remote_post to work. Specifically, we're going to do the following: When the page loads, we're going to submit some information to a custom script The script will examine the information and return it to our page We'll then display the data on the page Sure, it's a bit of a contrived example but it will give us the experience of creating a separate PHP script that can be used for operations triggered by the use of wp_remote_post. Anyway, for the purposes of this example, we are going to use the PHP $_SERVER collection to log when the user has submitted their preference rather than require that they have logged in. Finally, the source code will be made available on GitHub and accessible at the end of this series in the following article. For now however, let's get started with working on the plugin.Read More…
  • Code
    Creative Coding
    A Look at the WordPress HTTP API: A Brief Survey of wp_remote_postDiagram http api
    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 survey of the function 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.Read More…
  • Code
    Creative Coding
    A Look at the WordPress HTTP API: wp_remote_get - the ArgumentsDiagram http api
    In the last two posts, we've taken a brief survey of the wp_remote_get function as well as a practical implementation of how to use it. Before moving on to other aspects of the WordPress HTTP API, it's important to know exactly what information is returned from a remote call using wp_remote_get so that you're able to have a full understanding of the data that's returned, to write more defensive code, and to write more complicated requests should the need arise. So in this final article on performing GET requests, we're going to review exactly that.Read More…
  • Code
    Creative Coding
    A Look at the WordPress HTTP API: wp_remote_get - the ResponseDiagram http api
    In this series, we've been taking a look at the wp_remote_get WordPress HTTP API function in order to understand how it works, how we can use it, and the optional arguments that it accepts. From here, we're able to write detailed requests; however, that's only half of it - there's also the response. In the second article, we took a look at what a basic response would look like, how to evaluate it, and how to display it on the screen, but we didn't actually talk about the response in detail. If you're looking to write more advanced requests and write more defensive code, then it's important to understand the data that's sent as a response. In this final article, we're going to do exactly that.Read More…
  • Code
    Creative Coding
    A Look at the WordPress HTTP API: A Brief Survey of wp_remote_getDiagram http api
    When it comes to making remote requests within the context of web sites, web applications, and even WordPress-based projects, the model that we follow is generally the same: Initiate a request on the server-side Handle the response when it's retrieved either by reading the response or catching the error Return the response to the caller This particular format is the same that's used in both synchronous and asynchronous (or Ajax-based) functionality. The thing is, if you're building a standard web application using PHP, Rails, Java, .NET, or any other platform, then they each have their own ways of doing it. The same is true of WordPress; however, if you're working with WordPress, you're also working with PHP which means that you may be leveraging PHP functions rather than specific WordPress API's. In this four part series, we're going to take a look at what it means to make a remote GET request, and in the second part, we're going to take a look at a practical approach to doing so. Then in the last two articles, we're going to look at the arguments that wp_remote_get accepts as well as what you can accept from a response from the server when a request is completed. Ultimately, we should have a full understanding of this method's API as well as how to write quality and defensive code when implementing it in our projects. But first, let's take a survey of what it even means to make a request.Read More…