 Just a couple of quick questions. Who's used APIs and things where you've had to make requests, external requests from a website, bunch of people? OK, cool. So who's used Curl as a fallback? OK, a lot of people. Why do you do that? I have a theory on why that happens. And I think because it's developers were creatures of habit and simplicity and ways to streamline the ways we do things, a lot of code examples you see when you're going to use someone's API is it's pre-done in Curl. So copy, paste, use the code, and leave it at that. And I see plugins that are just littered with these really long chunks of code. Curl, it's a mess. It's like spaghetti code. So I think that's kind of why that happens. Curl itself, bad, is maybe a bit harsh. It's just not the best method to use in WordPress because we've got built-in APIs to use. So for those who don't know, Curl is basically just a way to make external requests, HTTP requests. It's not built into PHP core. You do need to use libcurl. So for the reasons, it's not always available on the server. So you can't write code that you're going to rely on something to be there, and it's not there. It'll break. So when you get into your writing plugins for people that you don't have control over the servers that they're going to install them on, you should avoid using those technologies. It's also not the only transport. There's some other ones you can use. There's a pair package, I think, and there's one or two others. So it's just not reliable. And it's kind of a mess to use. I hinted about this a minute ago. But if you've ever looked at the documentation for Curl, I've tried to, when I gave this talk in Columbus, I went to screenshot the documentation page, and it was like five or six screenshots long. It's not feasible to even put in slides. It's that bad. There's so much to learn to be able to use Curl as far as implementing it, and you're constantly going back to the function reference to see which ones you need to use. The WordPress HTTP API simplifies a lot of that and makes your job very easy. It's been around since 2007, or 2008, rather. It was version 2.7, and it got some improvements in 2.8 and a few more since then. It's got some very easy to use methods. So once you learn how to use it, it's dead simple to use. It's built to work with any transport available. So no matter what's on the server, whether it's Curl or one of the other transports, it should fall back and use one that will work. So as far as using it goes, there's four helper functions that you can use. Remote get, post-head, and request. They pretty much do what you expect them to do. Get's going to do a get request. The first three are actually all wrappers for remote request, and it just passes in the method. You can use remote request if you need to do something else, like a put or a delete, anything like that if you're working with APIs that support that. There are, they all take two arguments. The first one is the URL, and the second one is an array of arguments that gets passed in. They're slightly different between the few, so just reference that if you haven't used them before. A note on these ones, they do return raw request data. So if you're going to handle what comes back from these, you need to test for WP error, because if there's an error, that's what you'll get. So keep that in mind. There's some other helper functions that you can actually use to manipulate the request that you get back. And the last one down at the bottom, the safe remote, and it's the four from above. So it's safe remote get, post head, and request. If you're dealing with API requests where you have the URL as variable, maybe based on user input, and it's not hard coded in your code, make sure you use that, because it'll check the URL and help avoid cross site forgery requests. So handling the responses, these will give you a string back. So if it's WPR, it's just going to give you an empty string, so you're always going to get a string. You don't need to check types or anything like that. Body will get you the body back from the response. Header, you can pass in and get a specific header back or use headers and get the full array of headers back. You can also get the response code and the response message. Maybe you're doing something you just need to check uptime on a page, and you want to make sure that it's there. You can check and make sure you're getting a 200, and then you're good to go. So it just kind of handles all that stuff for you. Request for PHP was a library that was used, if you follow the WP REST API at all. This was a dependency. Ryan McHugh built this, and it's actually going to be swapped in. There's a ticket for, I think, the next version. I think it's listed in the earlier. They're going to try and get it in test. It'll drop in. The helper functions won't change, but it's a little bit more flexible. It's a little newer. It's based off, I think, there was a Python package that he based this off of. So there will be a slight change to it. It should help alleviate things and just kind of bring it up to date. But that's also a note. One thing I see a lot of people forget also, when I'm working in other plugins codes, caching, if you're doing anything with APIs, just make sure you wrap it in a transient or something like that. You don't want to make sure you're hitting API on every page load. It's also going to slow your page down and you've got to reach out and do external requests. Some API tools that I use for working with APIs. Postman is a free Chrome app. PAW, if you like a more polished app, it's OSX only. You can try it before you buy. There's also a MapBoins at LiInteractive. There is an extension for PAW that will take your API code that when you're testing it and you can manipulate URLs and things like that, it will create a little code block for the HTTP API. So it'll actually have all that drop in. You can just copy and paste it right into your code. There's a couple links here. The track ticket for getting requests in and as well the extension for PAW.