 I will wait for me now hopefully. My name is Jack Lennox. I work for Automatic. I am on the WordPress.com VIP team. The rest of the API has been an interest of mine for quite a long time. I have been playing around with it in various different ways. I have given a few talks about it. Obviously now it is very exciting because as John was saying it is about to go into core, which is amazing. Some of it has been in core as I will explain, but the real thing is about to start happening. It is really exciting right now. I have a habit of talking really quickly. I am going to really try and focus on not speaking really quickly because it is really hard for people to understand me. You are welcome to slow me down. Just put your hand up and say slow down. Especially once I get going I get really excited. Obviously John has given you a bit of information about the rest API and some uses for it, how it can work. I want this thing to go. This thing at the bottom is going to stay, I am afraid. No, it is not. It is going to go. The case for a WordPress rest API. Some of you may still not really have much of an idea of what it is because as much as you can see examples of it being used it is a little bit difficult sometimes to get your head round why this is such an exciting thing and why it is so important. We will begin with what a rest API is. John had a slide which he did not linger on. It stands for representational state transfer application programming interface. I guess that makes it really clear to everyone what it is for which is pretty much finished there. Obviously it does not. There is a whole load of philosophy and theory that goes behind rest and restful systems. I am not going to go into it too much because I think you do not really need to know. If you go on the Wikipedia page and look up what a rest API is it will tell you a lot about what it is for. The main point is that it allows data to be available in a human readable form without the writing of any code. That is one of the most fundamental ideas. It allows people to access the data from a website or from any system. It is not necessarily a website but it allows you to get data by going to a certain address. That is the key idea. I will not try to explain all this. There is a whole computer science degree in this. If you are interested it is interesting to look at where it has come from and everything. There are other APIs that you may have heard of. One of the most famous ones before rest or one of the most used was SOAP. If you google SOAP APIs that is what a lot of stuff prior to rest APIs was built on. Lots of stuff today is still built with a SOAP API. I cannot even remember what SOAP stands for. There are other ones but the rest API is the one that is really hot right now. It is the one that everyone thinks is the best going forward. The easiest to understand. Making the data human readable and human interactable with. Rest APIs are centered around verbs. We have these ideas of get, post, update, put, delete and more. There are others but these are the main ones. If you are interested these are the ones that you are probably going to want to know about. They are hopefully quite self-explanatory. Get is how you are going to get data from your website. Post is how you post stuff to it. Posting there are lots of different ways. Posting could be updating, it could be putting. You can also be more granular in this. You can specifically just update, put and obviously deleting is deleting stuff from your dataset. Rest APIs will usually respond in JSON or XML. I think according to the actual strict specifications they don't have to but that is the most common convention. XML was more common a few years ago. Hopefully you all know what it's extensible markup language. It's what HTML is. If you've ever written in HTML, HTML is the type of XML. XML is the syntax that uses those angle brackets. You start an element, you close an element by slashing. Hopefully you've all seen it. RSS is another big protocol that uses XML. For a long time it was the de facto way that everyone did things. Obviously because it's the way that HTML is written. Everyone really liked it. But the thing that's gradually got more popular and more people understand is JSON. Which is a bit less of a boast because it doesn't involve you having to open and close in the same way, like every single bit of data. In theory you can represent the same amount of data in JSON as you can in XML but it will take up less space. That's nice because it will be faster to load. It's all just a bit quicker. It could obviously still be lighter weight. In a work camp Prague last year and a guy in the audience asked me a question. He was like, yeah, but there's still so much extra brackets and stuff in JSON. He kind of has a point but the thing is that JSON, there are libraries for it in all of the mobile operating systems and everything. So yes in theory you could have an even more lightweight syntax like CSV or something which is even better. But there is this balance between making something human readable and making something that is fast. Obviously JSON isn't necessarily the fastest we could possibly have. But humans can look at it and hopefully when I show you some, you'll kind of be able to work out what's going on. Which is kind of, yeah, good. There's a really good talk. Sorry, that's my phone. There's a really good talk by a guy called Rich Hickey who's the founder of Clojure, which is a language and it's called Simple Made Easy. He talks a lot about how it's not just about having. When you're picking something that you're going to use for a project, you want to also focus on how straightforward it is to use the software, not just how powerful it is or that kind of thing. So JSON definitely in the moment seems to be the best balance between human readable and it loads quickly. So why does WordPress need one? I mean, if you've built themes or plug-ins, you're probably quite used to using something like WP Query or the template tags to get things like titles and the content and the date out of your WordPress posts. So you might be thinking, I don't understand, what's the point of being able to do another way of doing it? We need code to use WordPress, so why does this make any difference to us? I'm going to use an example. This is quite a strange example, but it's the first time I ever came across a REST API for WordPress because although there's a plug-in that we've been using which is going to become part of WordPress with the next release, the actual history of REST APIs in WordPress goes back quite a lot further than that. Does anyone know where this is? Does anyone been here? It is. So I like this example, because it was quite an elegant one that I came across. So it's also known as the MoMA, Museum of Modern Art in New York. In 2009, so seven years ago, I forget what year it is, they had a project. Their developers wanted to use WordPress as the CMS, but they wanted to use Ruby to build the front-end because that was the skill set of the development team that they had. So they were thinking, how can we mix these two things together? I have to say on the next one, I don't know why, but they did. But it's a bit crazy, I don't know why. I mean, I'm imagining, I think probably the most compelling reason why they would have been doing this is that their staff and their journalists and their people that are used to maintaining systems probably understood WordPress and there is no real equivalent of WordPress in the Ruby sphere. So if you want to have something that all your staff just know and they might already use it for their own blogs and everything, you're going to use WordPress, but obviously their staff use their Ruby developers. So if you try to imagine how you would get around this, does anyone here know Ruby? Has anyone used Ruby at all? Michael, yeah, cool. I mean, if it's not clear to people, it's going to be quite hard to interact these two things because there's no bridge, there's no way of building a theme in Ruby that would interact. You'd have to maybe try to connect to the MySQL database directly through Ruby and then you're sort of losing all of the power of WordPress because you're going to have to write basically all of WordPress again but connecting it via Ruby. So it's quite a complicated thing and their team thought, well, what we should do is build a REST API because we've got like one guy who knows PHP so he can do all the things that we're going to want to do in one go in PHP and then we can interact with it using Ruby. So they built this plug-in which actually, yeah, has been in the plug-in directory since 2009 and this is the first one that I actually ever used. I will tweet out my slides so don't worry about the URLs and stuff, but yeah, this is a totally different plug-in to the REST API that is coming into WordPress now, but it's really good. It's really fully featured. You could do all sorts of things with it. You could do the things that John's been talking about, getting data out, putting data in. You could have built something like Naimad Base probably with this. You could even extend it. You could add your own things to it. So, yeah, this is nothing new, like this idea of a REST API in WordPress. People have been trying to do this without WordPress actually supporting it for at least seven years and I think there's actually other projects as well that go back even further than this one. I think there's a SOAP API plug-in for WordPress. Yeah, people have wanted to do other things. So building something in Ruby is a really good reason why you might want a REST API, because unless you're doing something in PHP, you're kind of stuck. You can't really do much else. And partly as a result of this, WordPress.com actually released their own REST API in 2012 before I even worked there. I started working at WordPress automatic in 2013. I was going to say WordPress.com, not WordPress. So, yeah, the WordPress.com REST API was put together mainly because at that point, automatic became very involved in working on the mobile applications. And this is another example where PHP kind of has its limitations, because if you want to get data out of a WordPress website and show it on a mobile application, it's pretty complicated. You could theoretically write a bunch of, like, admin-age-axi things that can get the data out and send it back and have a whole bunch of, like, little URLs that do that sort of thing. And actually some people have even built REST APIs kind of like that where it's doing a little bit, just in a theme. There'll be a bunch of, like, admin-age-ax stuff that goes on inside it. But, yeah, it's basically a little bit tricky. So, this problem was identified, automatic, so they started work on the WordPress.com REST API. I don't think it was immediately available to all sites, but for a long time now, for at least three years, it's been available to self-hosted sites via Jetpack, which is really good because it's now being used throughout all sorts of apps. You can access self-hosted websites because it's been using a combination of the WordPress.com REST API and the XMLRPC API, which I will briefly mention. And now it's actually using the REST API, too. So, at the moment it's a bit complicated because it's using all sorts of things at the same time. But we're gradually converging and shifting everything. Like, anything new that's getting added to anything is going towards the new REST API that's coming into core very shortly. The main drawback to the WordPress.com REST API, if you're a developer, is that you can't change it. You can't do anything with it. When you activate it through the Jetpack plug-in, basically what WordPress.com will do is surf data from your site through its own WordPress.com URL. So we've got this public api.wedpress.com, and you'll go to that address and then you go to sites and then you type in the name of your website and you'll get your data from your website. But fundamentally, you have no control. The REST API is not in Jetpack. It's happening on our servers. So if you're automatic, you can't change it. And even I can't really change it because obviously I'll cause loads of problems if I start just making loads of changes that no one's asked for. So that's the limitation. But yeah, there's kind of a long history which is the point I'm trying to get across at this point. So this is the WordPress.com REST API. There's loads of documentation. Again, I'll tweak the links so you don't need to remember the URL and you can barely see it. My use cases that we have are anything that's not PHP. So yeah, there is Ruby. There's also plenty of other systems. You could be working on a desktop application. As John said, you might be working in Java. You could be working in pretty much anything. Yeah, literally you could be working in anything. And you won't be able... It will be very difficult for you to work with WordPress. So then we've got obviously mobile devices which is the most obvious thing that's happening right now because we're all using... We probably all have a smartphone. But if we wanted to build something on a smartphone ourselves that works with WordPress, it's bit difficult. Obviously you can use some of these other plugins that I've just said, but WordPress out of the box isn't going to work for you. But more recent, like the thing that's gone really nuts, which has probably driven this REST API development more than anything else, is this little thing you might have heard of called JavaScript. There's just endless things happening in the JavaScript world. All these new frameworks and libraries and it's all going completely nuts at the moment. This is just a small handful. No, nowhere near. Everything that's happening right now. I haven't even mentioned it. That reactor isn't even on there. This is just what I found from the JavaScript Foundation which is a new group that are trying to bring together all of these different libraries and frameworks and make them interoperably good. So yeah, the JavaScript world is going nuts. And one of the problems with WordPress in this whole equation is that if WordPress doesn't move forward to meet where developers are wanting to go because lots of developers like making stuff in JavaScript because you can make stuff that loads quicker and you can make nicer interactions between pages and all this kind of thing. I've got some good examples of that if you haven't seen websites that do this. If you're not going where the developers are going then WordPress could start to fall away and big competitors to WordPress like Drupal it's not big in terms of market share because WordPress is still miles ahead but Drupal also has a REST API with Drupal 8. So competitors are moving in this direction because they want to be able to work with JavaScript and there are libraries like Backbone that some of you may have heard of Backbone is used in WordPress Core for things like the Customizer but Backbone, if you do like a tutorial about it on Codeschool.com there's a really good Backbone lesson that takes you all the way through setting up an app in Backbone and it's entirely designed for working with a REST API that uses JSON. So yeah, you've got this kind of community thing where people want to use REST APIs and they want to use REST APIs that use JSON Ember as well actually is the same kind of thing and so WordPress at the moment doesn't cater for those at all but very soon it will do I've lost one of my things oh okay, anyway internet of things there is also a fridge, I don't know why it's gone so there's the obvious things, there's mobile devices, there's watches and then there's God knows what else is going to happen in the next 10 years with fridges and cars and all sorts of other applications and appliances that might want to use WordPress I'm not quite sure how a fridge would use WordPress although actually maybe it could have a list of all that you could have products and things that are in your fridge but it could link up with Amazon to yeah there you go so there could be like fridge press you had it here first so yeah this is like we've got the tip of the iceberg right now with watches and phones but there's obviously glasses there's loads and loads of things that are possibly going to be happening in the next few years so it's good for WordPress to be sort of future proof with these things so I've talked a lot about these different REST APIs but what is the WordPress.com sorry WordPress REST API I've italicised the because obviously we're talking about a specific WordPress REST API so for that you have this man to thank this is a guy called Ryan McHugh Ryan is from Brisbane in Australia and he's like a WordPress wonder kid I think he started contributing to CORE when he was about 11 he's really really really clever and in 2013 as part of a Google Summer of Code project so Google Summer of Code it's this big community thing where people can register projects they're going to work on they get a bit of support and a bit of help and they do it every year and so Ryan kicked one off in 2013 to build a REST API for WordPress and I think in his original proposal he thought it would get merged in CORE in like six months or something something crazy so three years later it's almost actually going in and Ryan now looks like a really old man three years is still actually really quick and I mean it's taken him a lot of effort he also managed to get some help from some other folks so the three main maintainers and sort of the developers of the REST API Ryan Joe Hoyle from HumanMade which is a big WordPress agency in the UK and yeah well Ryan wasn't the human made when he started building it but now he is so Ryan got a job through that and then there's Daniel Backhoober who some of you may have heard of and he's the key maintainer of WPCLI if anyone's used WPCLI so you've got like some good brains behind it and I think that's partly what's helped push it along and obviously like Matt Mullanweg who's the founder of WordPress he's been very keen on the idea since it first started but yeah he's also been very specific about how he wants it to work which is part of how it's taken a while to come in but I mean Matt's like that with everything that goes in WordPress because WordPress powers a quarter of the internet so if you're going to put something in you want to make sure that it works properly Ryan started a plug-in so it's a feature plug-in if people aren't familiar with the way that WordPress gets built one of the things that was settled on about three years ago actually is a way of building most of the new features that go in is to start them as a plug-in so someone will start building a plug-in which is what they want to see in WordPress and then over time people can activate the plug-in and see if they like it, see if it works how the person says it does, they can look at the code and then eventually that plug-in might get merged into a WordPress itself so it becomes part of core so the REST API has been a feature plug-in so since 2013 you've been able to install it as a plug-in and use it and it's all developed under this URL again I'll don't worry about the slides and yeah you can see the whole history of the whole thing here it's actually now into its version 2 so version 2 is what's going to be going into WordPress core I think version 1 probably will be there as well but the version 1 endpoints where it was decided about over a year ago now I think that they just weren't quite as versatile as everyone would have liked so a few architectural changes were made and version 2 started and that's what's kind of that so you might see version 2 in different places but it's effectively version 1 for the community so yeah don't worry about version 1 so a kind of weird aspect of this whole thing is that the infrastructure of the WordPress REST API was actually merged in 4.4 on the 8th of December 2015 so the infrastructure is all of the code that fundamentally powers what the REST API does so that's actually been in there since 4.4 and the way that the plugin has worked if you wanted to use it the plugin kind of knows if it's been added to a version of WordPress that already has the infrastructure it just knows which bits to activate and which bits not to so if going away tonight you want to start playing with the REST API then like with how it's going to be on the 6th of December pretty much because you can still just activate the plugin on WordPress 4.6 and it will just work perfectly fine obviously from the 6th of December it's going to be in there anyway and at that point I think the plugin will either automatically disable itself or it won't clash like there's no conflict so don't worry about having the plugin activated won't cause you any problems but yeah so I was getting on to there were no endpoints in WordPress 4.4 it was just theoretically there and I'll explain what endpoints are in a sec but the endpoints are coming in 4.7 so it's all happening, it's all really exciting so yeah how does the REST API actually work and what the heck is an endpoint which we keep saying so yeah REST API as I was saying right at the start they effectively interpret the URL and return a response and they work out from the URL what the person who's typed that in is trying to get RSS in some ways it's not massively different to RSS and actually if anyone's used the RSS feeds which have been part of WordPress since 1.9 you'll know that if you go to any WordPress URL and after the URL you put sort of dotcom dotcom.sg or whatever slash feed you'll get RSS and you can then add all sorts of queries to the end of that slash feed and you can get post types and you can get like you can paginate all sorts of things like that I've still got my Athens thing these slides are from my WordCamp Athens talk so I'm afraid that's why it says WC Athens ignore that but yeah so you can do something very similar with the REST API so we're just going to get things out you could say if you have the REST API activated on your website you go to yourwebsite.com slash wpjason slash wp slash v2 slash posts and to just break that down the wpjason that is kind of the root part of the REST API so it's a bit like wpadmin but it's wpjason so yeah you type it in at the same point one of the ideas that was added to version 2 of the REST API was this very concept of versioning the endpoints so before on version 1 you would just go wpjason slash posts and you would get your posts now the problem here is that if it was decided that in WordPress 5.1 they were going to change the way the REST API worked anyone who'd built anything that used the REST API was going to break because if they like changed, let's say they changed the like post title to the post title or something anyone who's using it they would like the post title would disappear because they're getting the wrong thing from the REST API so this concept of versioning was introduced and of namespacing so wp is the namespace that means it's like a WordPress endpoint because in theory if you're building a big plugin for example WooCommerce has support for the REST API and their endpoints are wc and then slash the version number so if you were doing your own endpoints you don't have to start with version 1 you don't have to start with version 2 but obviously for WordPress there's version 2 and then there's posts so this is one of the new things so post is the most important part here and that's saying we want to get posts so what we would get back from the REST API if we typed this in and we had the REST API activated would be something a little bit like this I've actually removed some of the things to just make it slightly easier to read because you get lots of stuff back at the top this is post ID 1 it's the Hello World post that comes with every single installation of WordPress you have things you're probably used to seeing like the date and the modified date the slug which is also known as the post name in WordPress so some of the terminology of the naming of these fields is actually to do with the REST theory so in REST you would call for example the link to a post you would just call it link so whereas most people here if you've worked a lot with themes and stuff you're probably quite used to the permalink the underscore permalink in the REST API you just get link and that's the same thing and similarly like title is just like title it's not post title or post underscore title content it's not the content it's just content but this is how things come back now you can just type this in in a normal browser and you'll get this you actually will get this without any of the spaces or anything and the carriage returns so it's going to look like just one big horrible string it's going to be hard to read there are a whole bunch of browser extensions that will add these line breaks to make it easier to understand what it's saying but yeah you will effectively get this back just in black and it will be quite hard to read but yeah this is like making it slightly nicer and obviously using colours and stuff to make it easier to understand what's going on but hopefully some of this will look quite familiar so we have things like title you'll notice as well that it's like nesting this other object which has rendered inside it and the reason for that is simply that down the line there might be other types of title that you could get and in fact it's even more relevant with something like content so for example content it will render it with the P tags that you get in HTML so WordPress does this thing called AutoP where every time you've pressed enter it's going to add paragraph tags in HTML so that you get like paragraphs rather than just a big long string of text because HTML doesn't know what a carriage return is it's not going to register that now that's all well and good it's not using something that's web based but if you fundamentally aren't using something that actually does anything with HTML this rendered thing could be quite useless to you you might say for example want to use markdown and you might want to get the markdown version of the content out of the rest API so at the moment it does just return the rendered content but you can actually add to this and so you could add like markdown could be another field under content or you could just have plain like a totally plain version that doesn't do any of the automatic formatting so that's what that's for it's kind of a full explanation of how the JSON works but yeah I've taken a few out so there are also other things you'll get back there are things relating to like the category the post type, the taxonomy all sorts of other like meta data that's related to a post but these are like key things that you've hopefully all used and seen over the years and here are some other examples so in fact I should also say like I'm only returning one post here so if I only have one post in my website going to the post end point will give me the one post I have if you have lots of posts in your website it will do whatever the default loop is for your WordPress site so like the default loop out the box is going to be the 10 most recent posts so that's what would actually happen here is you can see the square brackets at the top and bottom in JavaScript that's an array and it's I think the same in PHP so you would have an array of the posts so there'd be a comma at the end and then it would carry on to like next post next post and you would get 10 if you change it to 5 in your settings you would get 5 and so on so there's more end points and there's way more than this but just to give you examples of other things you can get if you want to get one post and you want to get that post by its ID let's say you know the post ID that top one will take you to one post so you won't get a whole bunch if you want the pages you get the same idea you go to pages and similarly if you want a page by a specific ID you put the ID at the end and again these concepts are to do with the way that restful systems work so although they might seem a bit alien that's just how it works if you want to get all your users you can do that and you want to get all your categories and hopefully you're starting to see the versatility of this this means that you could do all sorts of weird and wonderful things and if you are working with say a mobile developer or an iOS developer they're just going to totally get this if you're not planning to build anything yourself but you want to work with developers who are using other systems you can just say yeah we've got a rest API and they'll be like I understand all of this they'll know exactly because it's the same as like the github rest API reddit has a built in rest API which is very similar to this you can actually go to any reddit URL and type dot jason at the end and you'll get the jason rest API response for that page which is pretty cool so yeah people get this even though it's quite new to a lot of WordPress people but obviously there's more things you can do everything I've shown you so far most of it anyway you could theoretically do with RSS but actually getting stuff out of your website is already theoretically available with RSS and by default if you go to these URLs as I've just been showing you in a browser a browser will do a get request by default so that's what you're seeing that's what that jason was that came back but there are other types of requests that we could do we could do posts and puts and updates and deletes as I've been saying so this is kind of how you would process a form you can post things to the rest API now you might be wondering this is a bit dangerous it does not mean that people can like just add posts to my website update, delete things no because there are sort of two layers to the rest API there's the things that are publicly available by default and then there is authentication so in order to do anything that you would need access to your dashboard to do you need authentication so one of the controversies when the rest API was first coming into being is that people were really worried about the fact that this would actually expose all sorts of private information that they might have in their WordPress website and it could be really dangerous some people, one guy had an example of a website he had where he was storing customer transactions as a custom post type which was storing address details I think maybe even credit card details and this was already completely stupid because no offence to this man but you could already get that with the rest API with the RSS you could already actually get a custom post type out so the rest API exposes nothing publicly that's not already public from your WordPress website so if you do store customer details as a custom post type that don't require authentication stop doing that that's a really really bad idea because in theory yes, the rest API would make those available except that there is one thing when you're adding a custom post type something that's now been done by default is that it actually won't show in the rest API there's a thing called show in rest and you have to set that to true when you're creating a custom post type in order for it to be visible through the rest API if you don't see anyone adding anyone deleting anything like that that's going to want authentication so here we have a whole bunch of options and this is one of the things that's actually held the project up a bit because it's quite complicated so the most simple type of authentication is what's known as basic authentication and basic authentication is really easy it's great so if you're going to do a post request in the way that you would say post a form you can add a username field which is the person's username and you can add a password field so you can collect that from a form you can post it to the rest API really really bad news and so if anyone's used like Curl you can do the same thing you can do that the really bad news is that's obviously going to be passed over the wire in plain text so if you were sitting in a cafe watching someone use an app that you had built that did basic authentication without HTTPS they would see everyone's usernames and passwords being like in plain text and obviously log in so basic authentication is really good for developing and testing if you want to just check if something actually works you can use it at the end of this talk I've got a link to the documentation for the rest API and that they've got some great tutorials basically all of these authentication systems have plugins which make them accessible so basic authentication won't work by default you have to actually activate the plugin and then it will work basic authentication isn't so bad because obviously it's more secure it's harder to do this kind of listening thing but posting a password in plain text is just generally whether it's over HTTPS or not it's just still not very good practice so yes in theory it's safer but again probably don't do that cookie authentication is arguably the easiest because there's a lot more help here but well I mean basic authentication is very easy but cookie authentication is also quite easy and it's great for themes and plugins cookie authentication is basically going to do what WP Admin already does so when you log in to a WordPress website it creates a couple of cookies which for anyone who's not familiar is these little bits of data that are stored in your browser's memory and instead of constantly checking the username and password and everything it just checks this cookie is there and it uses that cookie to keep you signed in and it has an expiry and that kind of thing it's why it can be quite dangerous if you're on a public internet connection and you're logging in to a WordPress website with that HTTPS someone theoretically could get your cookie and then they can spoof being logged in as you and it caused a lot of problems in the early days with Facebook and stuff where people would sit in cafes and I imagine especially someone like Singapore where there's lots of people on laptops in cafes if the internet connection to a cafe doesn't require a password this is mega easy you can just sit and listen and see and obviously in airports and stuff you still see a lot of this so anyway I'm getting sidetracked that's why you should use HTTPS like a little side note use HTTPS it's available now for free so yeah definitely do that cookie authentication is going to use that same authentication that you're using for WP admin so all your user is going to have to do is login the way they normally would and once they're logged in they can be authenticated through the REST API so you can use the same login system that you already have let's say you have like a dashboard for managing HR things like John was talking about you've got like an HRM you could build a theme that's all built in like React and all sorts of lovely JavaScript things so you can use it to login like they normally would and then you can start doing all the admin kind of things that you might want to do and then we get on to the OAuth which is like so OAuth 1.0 is the most versatile because the biggest problem with OAuth 2 is it requires HTTPS now as I just said isn't HTTPS a really good idea shouldn't we all use it yes we should but this REST API is being added to WordPress which powers 26% of the internet and the vast majority of WordPress websites at the moment still don't use HTTPS so we need something that is usable by people and that's where OAuth 1.0 comes in so the way that OAuth works I should have like a little animation actually that shows this but anyone who's logged in using their Facebook account or their Twitter account or their Google account to any other service you know where you can log in with Facebook or sign up with Facebook that's OAuth so when you get this website wants to use your credentials to be activated on this website are you okay with that and you click approve that's the OAuth system going on there and what basically happens behind the scenes is that some tokens are exchanged you get like a private token a little bit like the cookie thing but it's independent of cookies you have a private token and then you can use that token to authenticate yourself in future so OAuth 1.0 is pretty good because it kind of deals with all of this and it gets around the HTTPS thing by being a little bit more complicated which is why it's not the easiest thing to use but it's theoretically the most versatile and actually the core team behind the REST API have put most of their resources into that because that's the thing that everyone can use and OAuth 1.0 is even better obviously over HTTPS but if you are using HTTPS you can use OAuth 2.0 OAuth 2.0 has had a lot less of focus because if you just google it there's great things about how to get it set up and running OAuth 2.0 is what the WordPress.com REST API uses because WordPress.com this is part of why WordPress.com doesn't serve its REST API stuff REST API about 100 times in the last hour but it serves it through our URL because we can then make it HTTPS which kind of deals with all of these problems this is why it all gets a little bit of a pain but yes, so OAuth 1.0 is the way that you're probably going to want to do things unless you're happy using HTTPS and stuff so there's a whole bunch of documentation I've got a link at the end the biggest problem with using OAuth 1.0 is that it creates these tokens and if someone does you need to store those tokens somewhere so you might store them as a user meta variable or something for your users though it also then becomes complicated how do you get them out because how do you authenticate yourself to get the user meta to get the token back out which is a little bit of a pain and then obviously also if someone did hack into your system they'd have all these user tokens and it's really hard to then you have to build your own system to invalidate a token if there's a user who's gone rogue if someone's stolen their phone how do you stop that user being able to activate it gets pretty complicated quite quickly so something that the REST API team have been working on is what they're calling brokered authentication so in this system the WordPress REST API team are the broker and they basically are storing all of this data and you authenticate with them and they authenticate with your website and then it's kind of this big two-way thing so then when you want to authenticate they'll send you the token and they'll write HTTPS so that's how this whole thing kind of becomes safer if you go to apps.wpapi.org you can set up any website that you want to use this with it's totally free and actually the software they're using behind this is also open source so you can actually, if you're running a big business and you don't trust them, which is reasonable you shouldn't trust anyone you can actually run the same software yourself so you could run apps.yourwebsite.com and you could have this at your own broker or HTTPS and then all of your other properties let's say you're a news network and you've got lots of subsites and everything you only need HTTPS on the one website and then all your others can carry on working I'm probably boring you to death now talking about authentication but it's a bit complicated so it needs a bit of time I have got there was a really good talk by a guy called Joe Hoyle who we've already mentioned he spoke at WordCamp Europe earlier this year and I would recommend watching his talk where he talks about this in more detail it's a really good talk and it's free on WordPress.tv Modifying and adding endpoints so I have this slide but I actually don't have any example code there's some really good documentation on the API website I'm going to skip this now but if we have, where are we up to I'm actually running out of time so we could do this maybe in the question and answer section if people want me to look at it and I can show you it but the documentation is really good the key point of this is that you can modify and add endpoints as you might guess from what my slide says so here's a good example of why you might want to modify an endpoint when I showed you what comes back from the REST API when you're looking at a single post if you were building say a theme there are certain things that you might use on a per post basis that you're not getting back from the REST API so I've built some themes that use the REST API in JavaScript and for example post class is something that you normally want because you use the post class for styling and you're probably going to want that to show up somewhere so you could modify the post endpoint I've done this and I'll share it somewhere on like a github gist or something and you can see how it's done you basically can just add post class in to the REST API at the relevant point it's really straightforward because you can just pass post class an ID so you're just basically going to extend the API and say like take the post ID add post class to the response that comes back and you'll get the post class adding endpoints gets into a whole new world you can actually set up as I was saying WooCommerce has like its whole own namespace and everything so they've got like a whole host of new products so products as endpoints and all the other things that they use as endpoints but you can just add like one to say you just want to add an endpoint for a custom post type where you're going to do something a bit different to what normally happens you can also just do that there's great documentation there's register REST field and register REST endpoint I think and they're just like hooks in the same way that other WordPress-y things work so we can look at that maybe in the question time I'm getting quicker so I'm going to slow down again right we're almost done there with me so uses for the WordPress REST API so we've obviously talked around a lot of the things that people might want to use the REST API for and there are now some very good examples emerging of how it can be used so one of the most popular is this sense of what John talked about a custom interface like a custom admin interface to WordPress if anyone has ever tried to hack WP admin you'll know it's hellish and most people that try to do this they actually normally want to remove more than half of what WP admin is doing anyway because people find WP admin very confusing for people who've never used WordPress before they're like whoa you're kind of giving them especially if the user is an admin they have all this stuff they don't necessarily need to know about so yeah if you're trying to hack WP admin it's a nightmare because it's not really designed to be hacked you can add stuff to it and you can make little changes but to actually unhook all of WP admin and then obviously you're losing the access for you have to unhook it on a per user basis because you probably still want one user who has full access anyway with the REST API you can just start from scratch so rather than starting with WP admin deleting everything you can start from scratch and only add the things that you actually want on WordPress.com if anyone here has a website on WordPress.com you'll notice that the dashboard that you now see is not WP admin and that's this project called Calypso which we've been working on Calypso is built with React and lots of other JavaScript libraries and it allows us to tailor the experience to people on WordPress.com so it's really nice anyone can see it by just signing up for a website on WordPress.com another really nice example which is totally different to that is that Happy Tables is a project a project product that's the project project a product I've been on a long flight so Happy Tables is a product for restaurants and it gives them a custom admin interface to deal with a whole bunch of things that you would want to do while running a restaurant day to day Happy Tables started this is what I was going to try and say as a hacked WP admin and this is part of where their enthusiasm where Human Made is the company behind Happy Tables and Ryan works on this this is partly where the enthusiasm for the REST API came about but the new Happy Tables it's gone through four or five versions now the latest one is an all singing all dancing amazing JavaScript interface that it can be set up on iPads in the restaurant and the servers and waiters can come up and they can say we've dealt with that table there's a bunch of different storage of details but it's effectively a custom WP admin interface and there's a whole bunch of custom post types and stuff running beneath the scenes that make all of that work unfortunately unless you work at a restaurant where they have it you can't fully see it but if you go to happytables.com you can get a sense of how it works I don't think it's open source but yeah it's interesting mobile applications are really obvious one so there's the WordPress mobile apps which are open source they are led by Automatic and WordPress.com but they are open source anyone is able to contribute to them the problem is that most WordPress people are not mobile developers that's why they're WordPress people so there's not a great overlap in the Venn Diagram but yeah so they are mostly led by Automatic but you can see how they work at the moment the mobile apps are using a horrible mixture of the XML RPC API and I will very quickly give a tiny subnote to the XML RPC API this is another way of doing a lot of the same things that the REST API allows you to do it's just way more complicated and the protocol is a lot harder to understand yeah it's in its essence it's not that different but the main problem is the barrier to entry and the mobile development platforms are not as ready for dealing with an XML RPC API as they are a REST API neither is any of the JavaScript libraries so it could have been the REST API but it just sadly hasn't really worked in the same way but the people who built the WordPress apps did bash it and make it work so it does work they use a combination of the WordPress.com REST API and as of about 6 months ago anything new that was being added to the apps is now on the WordPress REST API a much more pure example of an app that uses the REST API is one that Joe Hoyle again made he's a great guy so if you go to github.com slash Joe Hoyle slash Vienna he showed this off at WordCamp Europe that's why it's called Vienna it's an app that purely uses the REST API it's only for iOS at the moment but if you've got an iPhone you can download and install it and it's all WordPress REST API there's no .com and no XML RPC so it's a really nice pure example it also uses the brokered authentication so if you want to see how that works in a public example you can see him using the brokered authentication in that app Themes this is a whole another field which may interest or not interest some of you there are lots of potential this is kind of my other think talk which I give about my theme Picard there are lots of potential user experience improvements that can come about from using JavaScript to build a theme and obviously then you're going to want to use something like the REST API one of the biggest things actually which I think is going to be none of these themes use this but something to think about is that there's a new browser technology called Service Worker so basically once a user has come to your website you can download things using service workers to decide what things are going to be stored offline then when the user comes back to your website it's loaded from the memory first and then you can decide which things you're going to update the thing that's crazy about this is that this is still really new it's still very cutting edge but I reckon in like five years time clients are going to say like why doesn't a website work offline in the same way that now clients expect responsive websites responsive web design I think it was in 2011 at the future web design in London he was kind of talking about responsive and everyone was like oh this is really exciting and no one had ever heard of it and it was completely nuts and this was like five years ago and look and today like my dad knows what a responsive website is and you know he's a luddite and hopefully he won't watch it and yeah he would be he knows what a responsive website is and he will judge a website as not being very good and if he doesn't work on his phone properly he's like oh why is it not working so it's only a matter of time before clients say why doesn't my website work when there's no internet connection so these are things like when John was talking about us needing to move on but this is something where JavaScript could become more important than PHP and sort of already currently is that's one very good example of a user experience improvement there's lots of smaller improvements like animations and you can preload things so in Picard for example it loads the 10 most recent posts on the homepage from memory because it's already got it because when it's gone through the list of posts it knows what the content is so even though you're only seeing the title of the date and stuff and the excerpt maybe you click it and it's instant so you're removing a page load to zero rather than it being even a second or something so really good and very good for mobile experiences if you're on a bad 3G connection I know in Singapore no one really knows what a bad 3G connection is but if you leave Singapore data connections get really bad like in Greece where I just was and you really love it when a website doesn't have to refresh each page load just to get you some more content in London when you go on the underground you have no mobile connection so these things are really exciting but obviously in Singapore you have 4G everywhere so it's not a problem anyway so there's my theme Picard which is available through the automatic user account Picard is horribly out of date it's using version 1 of the rest API I can't really recommend that you look at it but it's not actually bad as like a museum piece so it's about 18 months old now and I'm really bad at maintaining it but it's not actually so bad to just look at to get a sense of how React works and how you can build a theme much better maintained versions of the same idea are by my colleague Kelly Dwan the automatic so her username is Rael on github she's got anodama React which is like a recipe theme and Foxhound which is a very text heavy theme both of them are easier to understand than mine but then she does use some more complicated things like Redux if no one's ever seen Redux whereas Picard is like really like just taped together with like Pritt Stick and stuff so it's much easier to understand how it's doing things whereas Kelly's is more advanced and cleverer plugins as I've mentioned we've got things like github sorry github that's not a plugin WooCommerce so if you go to the WooCommerce plugin you can see how they're doing their like crazy rest API stuff where they have slash WC slash whatever a much more simple example is easy digital downloads EDD some of you might know by Pippin who's a famous plugin developer in the WordPress world he's also just got some quite simple extensions on the rest API using the sort of modification and adding thing that I was talking about earlier and there are loads of other plugins that could really benefit so automatic I help work on a plugin called the push syndication plugin and it's an absolute hell because it uses like CLI and all sorts of weird things and like with the rest API it would work much better just to quickly I didn't explain what it does we have some big news networks where they have like a central so CBS for example have a central news website on wherepress.com and then they have a whole bunch of local versions of the same thing and every now and again they'll have a new story that they're going to put on CBS central that they want to go to all of their local websites as well so we have the syndication plugin which in theory quite nicely allows them to just do that they just say yes I want this post to go everywhere and it also connects up for updating and everything as well and at the moment the syndication plugin which I've been working on recently is just like the underworld it's just not pleasant at all but it could use the rest API and we're probably going to push it that way over time and so there's loads of plugins you've probably used and maybe plugins you've made that would be better if they use the rest API instead of whatever they've used to try and do the same thing and then the really exciting thing as well that's been going on in this sphere is like enterprise, big websites big companies and as I was saying there's this kind of offline thing that people are expecting so Quartzqz.com I've used this example before it actually uses the WordPress.com rest API but you get a sense of some of these much better user experience things that can be gained from using it a much more recent and another WordPress.com VIP client is Facebook if you go to facebookbrand.com it's really really nice it's all built in React it's really sweet and it's really nice on mobile and you'll see there's like no page load times between clicking links and stuff it's just really really really nice and then if you want like the most extreme example I can think of today it's not WordPress but it's kind of a sense of what I was just saying about this JavaScript world go to the Google I O website I could have actually had links to these but because I was in Athens and the internet was terrible I didn't but obviously you can check all these out Google I O is just incredible so their website for the event they had this year 2016 it uses this service worker thing I was talking about so as you go to it it'll have a little thing that pops up and says yep I'm now ready I'll now work offline you can turn the wifi off on your phone and it'll just carry on working it's really nice especially for things like conferences where you're going to have schedules and that kind of thing where you don't know all these people are just constantly hitting your server and hitting your wifi to check the schedule when the schedule's not changing like it might change once every you know it might change because of a last minute thing but yeah it's really exciting for that really exciting for like hotels and stuff where people can already have the data about a hotel and they can arrive in a foreign country with no data roaming and they can still access the hotel website get the details get the directions loads of exciting things that can be done with this it's a whole new world as Aladdin says but anyway very exciting times ahead so here's some links and any questions I've overran slightly sorry about that so v2.wpapi.org that's the current place where the documentation for the REST API has been I must have been I didn't know about what John said I think he told me the other day so I'm guessing a lot of the stuff that's there is going to be shifting to the REST API handbook but there's plenty of stuff there at the moment if you do want to find information right now and obviously hopefully the REST API handbook is going to become really good as well there's a whole load of talks about the REST API on WordPress TV I haven't gone too deep on a lot of the different concepts because there's better talks, frankly, that you can already see so yeah, you're just such a REST API I'd really recommend the one that Joe gave at Workham Europe from earlier this year and if you are interested in learning JavaScript and it's quite new to you and all of this stuff is sounding a bit intimidating there's a really good WordPress course led by a guy called Zach I've just completely forgotten his surname I should know his surname anyway, Zach is the guy who was doing WordPress courses on Treehouse if anyone's used Treehouse he was the WordPress chap and now he's got his own little spin-off thing so JavaScript for WP.com he's got loads of courses that look into all the different ways that the REST API can be used different ways that JavaScript can be used so although he's mainly talking about JavaScript it's inherently about WordPress a lot but yeah, any questions? so I don't know if something's really good or really bad but there is actually one thing I was going to add I've got a question for myself oh, I don't like JavaScript this sounds rubbish there's actually good news you don't actually necessarily have to use JavaScript and one thing that I think is an interesting thing I would add to what John was saying is does this mean that JavaScript will become more important than PHP? not necessarily because there's a new technology coming to browsers that's going to be in probably the next few years called WebAssembly and yes, it's actually, believe it or not, assembly language for the web which people think is great because the web is gradually degrading into we use make and things like that now instead of gulp and it's going back to the 70s so the really exciting thing about WebAssembly is that it will actually mean that instead of having to use JavaScript which is the only scripting language that's built into browsers other languages could potentially be supported by browsers inherently so something I've been getting really into lately is a language called Elm if you go to elmlang.org it's nothing like JavaScript at all at the moment it compiles into JavaScript so to run it right now it has to be compiled but there's a good possibility down the line it will work remotely it will work itself on browsers it could work itself on fridges so there's a whole load of languages there's like PostScript and TypeScript all these other scripts which are different versions of JavaScript at the moment what they all do is compile into JavaScript Elm is a functional language it's really nice to use the compiler is all based around helping developers have a nicer life so the guy who made it wants to make development fun again but that's his credo so it's a really nice language to learn really nice language to use I'm currently building a WordPress theme in it which I'm going to share at some point but if you really don't like JavaScript which is totally reasonable there are other options it doesn't do it has like static strict types it kind of forces you to think about things that you wouldn't normally worry about with JavaScript so things that would just break normally it deals with all of those and the biggest bonus that I've found so far is that you have zero runtime errors you never have like undefined is not a function if anyone's familiar with that that never happens because it has a compiler because it's so static and it's so strict about how it should work it will know exactly how your code should look so the compiler will stop you compiling anything that's wrong and it has these lovely messages where it's like oh you've passed me like a boolean and I think you meant to pass me a string I reckon the problem that came from this line and I think this is what you need to do to fix it and often it will actually include like the fix in the compiler it will tell you what you need to do to fix the problem it's really really really nice so if you're having like JavaScript fatigue there was a really good post on Medium recently where a guy was saying what it's like to learn JavaScript in 2016 where he was talking about this like hellish just end the list of new things you have to learn if that's all kind of driving you mad then yeah I'd really recommend checking out some other things and for me Elm is the one to look at I would really recommend that yeah it's really exciting any other questions is there any way to install or change the authentication on the Res API so yeah none of the types of authentication actually come by default they're all separate plugins yeah so there's an authentication page on the V2WPAPI so if you want basic authentication you add that plugin and similarly like if you want your own authentication you can write your own additional plugin it's got a really nice like the authentication hooks are quite nice so you can just basically add your own functionality but there are plugins for OAuth 1 or 2 I think cook your authentication might work by default that might not be a plugin I'm not actually 100% sure but the others are plugins yes yes I actually saw someone talking about this I think there's actually there is already a plugin that someone has made that uses JSON web tokens so that already exists but it's not officially done by the Res API team so Res API plugin and it's been about a year since we've had that project at the forefront of what we're doing so it's on the back burner right now but December 6th we're trying to switch over to the core API so we have to bring that back to the front and update all of our custom stuff could you just mention briefly how do you add or modify in points like over over view in our environment ok so so there's a couple of ways so if you want to just like you're probably talking about the more advanced way I'll start with the easier way there are methods that are just available like global methods there's one called register rest field and one called register rest endpoint so to modify you can use register rest field it takes something like three arguments so you create a plugin an extra plugin to modify you can just literally create like a function which will just like take where the rest API is at that moment so you can modify it so you can add an extra field into it just for like a php array thing maybe part of the theme I probably recommend doing it as a tiny little plugin a little drop in or it could be part of your theme and then it's the same for the endpoint so you can just add an endpoint and they just basically hook in they're just like standard you do like add action there is also like a more complicated you can actually instantiate your own version WP rest server I think it's in I'd really recommend actually that talk rest API Joe Hoyle work at Europe if you watch his talk he'll cover that in much more detail but yeah there's WP rest server and from there you can just like build your whole API again so you can like you get all of the same methods they use to start with and then you can say what the namespace is going to be you can say what version it is and you add all your own stuff yes you want to see that in the wild yeah go on to the WooCom S1 and you can just if you just go into GitHub and like search their codebase for like WP underscore rest you'll find like a whole bunch of where they've used it I think we just have like a couple of custom metas stuff and like some multi-lingual hacks for one of our sites I don't remember but yeah you should be fine because I've at various points I've kind of like made my things against the rest API they're not updated it so I've kind of had a similar problem to you being it doesn't take much to bring it back into sync like you're just like oh okay I mean I modified the endpoints for version one and that was quite a different setup but it took me like an hour to work out how to just transpose those and bring them to version two so hopefully won't be too bad and if you forked like a year ago very little of the fundamental way it works I think has changed that much there's some like naming stuff has changed and like back in version one like ID was capitalised ID and capital letters and believe it or not that like broke everything of my website because it presumed ID it presumed it was capitalised when they made it lowercase like everything just went wrong and I got undefined as not a function but yeah there's little things like that but otherwise it's quite easy If you have short quotes within your post and you want to pull out using the rest of the API how would that be rendered now? So because the default state of the content is rendered, they are automatically rendered so what you get back from the rest API for content is HTML so it will actually already process those short codes automatically so that's a really nice thing actually I mean obviously if you're building something like a theme a lot of plugins might break something like Yoast SEO that relies on page loads so if you're changing pages without doing a page load Yoast doesn't know that you've changed pages so it doesn't change all the meta keys and stuff but anything that filters the content will work so I was quite delighted to discover just by chance that the Jetpack comments and liking system that all automatically works because it just adds it after the content in the content so it comes out fully rendered and it just works like the little like buttons at the bottom and the social sharing and everything that all just works even if you're doing rest API stuff I'm glad that the logic of the rest API was because to make sure all the filters worked so that's the other thing I mean I imagine Yoast SEO is actually they're working on improving their support for rest API stuff so I think they're going to add endpoints so that you can update the meta keys and stuff when you're the meta fields when your pages change and that kind of thing does that answer your question? yeah cool so in this case a render is basically what is after going through on a filter so will there be any point where you'll provide a raw field to provide an actual value in case I say we want to play before the filters so I say in title we've rendered in content we've rendered will there in future be a field called raw where you can actually get a raw yeah a plain version yeah I'm actually I thought that was going to happen before I mean John might know more than I do I thought that was possibly going to happen before because you can do it yourself really easily you can modify that endpoint right now and I think there are even some plugins floating around that do exactly that that will do like a raw or a plain version of the content but yeah so I don't know if that's going to be added I imagine it might I suppose the main thing there is a discussion about how short it is at the end there's definitely a lot of requests for it so I think the main thing is trying to make the rest API as like minimal as it needs to be for everyone there might be like optional things that you can just activate that would allow other things to work with it because I wanted them to put post class in because I was like well anyone who's doing anything front end with a post probably wants to post class but they were like well that's not very resty and you can just easily add it yourself so I was like okay fine if you can indicate a page number so let's say slash post slash one so the page number will be like it goes to once I'm near that so let's say I'm getting on post track so let's say so how let's say the page number of the number of posts that I want in the library industry so there are other arguments that you can add to the end of an endpoint so you can actually do anything that WP query does with what are known as these little filter arguments so you do like question mark and then you can say open square bracket like you can say posts per page close square bracket equals and then you can say how many pages you want per page and you can also paginate in that way so you can then say like which page number not to do with like wordpress pages but if you want to say page two post per page 20 so you're going to get pages posts 21 to 40 like you can do all that kind of thing so in the library industry specify whether I want to render or draw for my or then able to sorry yes yeah you could use that but yeah there's loads of ways you can extend the endpoints and you can actually one thing that I came across quite early on which anyone who's building a theme might struggle with is you don't normally know the post idea of a post until you get the post so when you're building a theme like how do you get a post by id when you don't know what the id is like if someone's coming to your post id into a specific post unless you put post IDs in your URL you don't know what it is but the really nice thing is you can also filter by post slug which is basically finding a post by its name so this is something I did quite early on is I took so like the way my theme the way Picard works is when you go to a post it will take wherever the post name is in your URL structure which you can get because that's an option in wordpress so you can get the option and work out where the post slug is you then use that slug to get it from the rest API and then you get the post back so you can get posts by their name you don't have to use the id which is quite if you anyone tries to do this you'll find quite early on like I don't know the id so yeah that's one way around that all good thank you very much was I too fast I'm really sorry but yeah if you want to come and work at Automatic then we're doing lots of fun stuff with this so automatic.com if you want to ask me any more questions I'm at Jack Lenox like almost everywhere on github and Twitter and Facebook and everything else so yeah thank you