 Super excited to be giving the last full 45-minute talk of the conference here. And thanks to y'all for sticking around. And we're going to show you some fun things, some interesting things. The biggest thing that I kind of want you to take away from this is we're going to go through a lot of different use cases, a lot of different fun demos. I wouldn't expect you to take all of these demos away and implement every single one at your publication. What I'm trying to do here is show how, in my experience, I've used the REST API to implement different interfaces for people and how it can work. But this is not like use every solution that I'm showing, because one might work for your organization, your audience, another might not. But there's a lot of different options. So that's why we're going to take a look at those. So this is a quick way to get ahold of me at K. Copenhaver on most every form of internet social things. Oh, this is my title slide that I thought y'all were looking at for the past two minutes. So this is how to get ahold of me at K. Copenhaver on most. GitHub, Twitter, all of that. Also, feel free to email me anytime. And so you're not distracted with pictures or note taking or whatever. All the links in the URLs and resources and stuff from this talk, including the slides and the link to the video when it goes up on WordPress TV, will be at that third URL there on the bottom. So it used to be we've done a lot of talking this conference about how the internet used to be or how you could put up a site on GeoCities or whatever, and you could just have all your content live there. But any more, NoSite is really an island. Your site and your publication, your content becomes much more valuable when it can integrate with other pieces of data, other service providers, and things like that. So just a quick example, put Chicago into Google here. And when Google started, it was just a list of links. Search results page now, depending on what you search, they give you a much more rich experience. So these things in red are some things that I've identified as probably pulling from some sort of API or the things. So we've got our top news stories, which are not strictly Google search results. Come from other publications, some maybe of yours in the room. We're pulling in a map from kind of an external source. We're pulling in this collage of images from an external source. Down there in the Chicago box, you can see what the weather was. Whenever I was looking this up, I think it was last Thursday at one in the morning. And then if you scroll a little bit further down the page, they've got these other blocks of content too. You can see how much it would cost you to stay in a hotel here, which is pulling from a different service provider, and then things to do in Chicago as well. So this is just one example, but you can look at any site, and chances are you'll find somewhere where it's integrating with something else either, just as simple as you can share this on Facebook, which is through an API call, or it's pulling in all this external data to function. So a lot of the syndication formats and ways to get your content out there, for better or worse, basically make you change your content as it lives on your site. So for Facebook and SNarticles and AMP, you can make modifications to your content before it gets served up through things like the is AMP endpoint function and things like that. But in an ideal world, at least from my perspective, you should be able to just have your content live on your site as unencumbered as possible and then let whatever interface you're sharing it to handle sort of the front end. So this is where the WordPress REST API comes in. For a long time WordPress has talked about how it can be more than just the blogging platform, it's more of a content management system, and something that was really holding it back for a while was there was not a great way to get that content to another service or integrate it with something else. So I know that when I found out about the WordPress REST API, I was super excited and started messing around with it and I just want to give a quick shout out to those of you who are in the room who have helped me with the REST API and things, because I think it's pretty cool and I think it's an awesome piece of WordPress that even though the adoption has increased since it came out, it's still growing to this day. So the WordPress REST API initially, the content endpoints shipped in version 4.7, which was December 2016, so just about two years ago. And it brought, like I said, kind of a standardized protocol like here's what WordPress data looks like to other services that want to integrate with it. It comes with a lot of content endpoints out of the box, so things like posts and all the stuff we saw in the last talk in that structured data tool. But also you can build your own and a lot of what we were doing, especially initially when the WordPress REST API came out was building our own kind of one-off endpoints. So we don't necessarily need a list of last 10 posts, but we want to build an endpoint for a specific piece of data that we can get out and integrate into a different service. So we'll see an example of that a little bit later. It's nice because, like I said, it standardizes the format and the return of data. It outputs JSON. I expected a few more laughs at that one. It outputs JSON, which can be easily parsed by most languages, JavaScript, Python, all of those have JSON modules, and they kind of understand that format pretty natively. And using the REST API to integrate with something else is opposing to kind of trying to change the post output and the content output. Let's WordPress focus on what it does best, which is content management and not formatting and trying to get all these different things that you need to display your content in some of these new interfaces. And the end result of this, that instead of thinking about your site as mobile first or print first or whatever, as we get more different interfaces that could be first class citizens, you can really think of it as content first, where all your content lives in WordPress and different versions of it can live elsewhere on the internet, but it all comes back to kind of the hub, which is WordPress in that case. So we're gonna look at a lot of examples of this statement today, but the web is not just a browser on a desktop anymore. It started with browsers on our phones, and then it started with okay, well now we have native app experiences and progressive web apps, but even now we're into things like voice interfaces and some other things that we'll talk about. So internet of things is huge in that regard as well. So when we think about the web and the open web, of course, as it pertains to this conference, we can't just think about my laptop or my phone or we have to think about how our content can live on all these different devices, which is why it becomes more and more difficult to customize your content for each of those devices within WordPress and where this kind of REST API decoupled paradigm that we've been talking about becomes even more powerful. So if it's not just a browser on a desktop, what is it? We've already been over a few examples, but we're gonna go over a couple more in depth here right now. Let's do that. So a single page app kind of lay out which is a pretty popular format in recent years for websites that aren't backed by a content management system, but it's slowly creeping into the WordPress ecosystem as well. And I'm actually trying really hard to think of an example that I could use to illustrate this concept. Ah, yes. So I hope all of you were here for the TechCrunch talk that was just proceeding to mine. Not a lot more to say. That was a really in-depth awesome presentation and I'm glad we were able to take a look at that. But basically, using the WordPress REST API, they can feed the content to their front end and do all the cool front-end-y things that the designers and the product team wanted to do, which makes it a lot more flexible and powerful. So we just had a great 45-minute demo. So we're gonna jump past this one for now, but definitely if you haven't seen TechCrunch since it relaunched, check it out and just kind of scroll and see cool things like the X button to close out an article slowly fills up as you read the article to show kind of a progress indicator. And lots of cool, interesting things that you're not used to seeing on WordPress. So, moving kind of off the desktop and onto mobile. We've seen a lot of cases where a publisher will have a mobile app and they'll have the mobile app doing its own thing, but then they also have the news side and the news is all powered on WordPress and they wanna bring that into their mobile app. So the REST API is a super powerful way to do this. For the example that we're gonna show today, the app itself is actually built in React Native, which lets you write it in JavaScript and then cross compile to Android and iOS. And at the core, it's powered by the REST API. So this one screen we're gonna show is just kind of a post timeline view, which if that was the entirety of your app, I would suggest you just do a responsive website or something to that effect or a PWA, a progressive web application. But what we've done in the past is integrated this as kind of one section of a broader app and this piece in particular is powered by WordPress. So all these examples that we're gonna show today are up on GitHub and open source, so feel free to check those out and ask me questions about them either now or later. But let's just take a look at this. So we've got it running here in our trusty iOS simulator. And basically it just launches, let's see, super dramatic transition. So you can see it just launches, this is not fully built as either, it's still basically running in development mode, so it's not an APK for Android or an iOS app yet. But this news feed just basically lives here and we have all these posts with their different featured images and excerpts. And you can do things like link this up and then you can click Read More and have it either open in its own view or kick them back to Safari or Chrome to read the whole article either in the app itself if you want to kind of keep that whole experience as one thing or in their preferred internet browser. So these posts, again, are just coming from the REST API. We can see that we have everyone's favorite theme here. And these are the same posts and this is where the content's actually living in WordPress. So these are the posts as they appear on the web and then the same posts basically appear in a native app experience, which is pretty cool. And again, because this is React Native in this case, it can cross compile, which makes kind of a really clean workflow from writing your content to getting it on the web to getting it on mobile. All right, enough scrolling, let's keep going. So another thing that's been on the rise and a lot of the questions we've been fielding lately are how voice interfaces like Alexa, stop. I forgot that there. So one of the things about voice interfaces is they sometimes trigger even when you don't mean them to when you try to invoke them. So Alexa and Google Home have really been increasing their market share of both devices in people's homes and usage as far as search and interacting with web services. This also includes things like Siri on your iPhone. Google Assistant actually is not just on Google Home, it's also on most Android devices. So when we think about how we can provide this kind of voice functionality for our WordPress content, it comes down to basically either using the endpoints that come with WordPress to let someone read the latest posts from your site or post of a certain category if they have a topic they're invested in or building custom endpoints to expose custom data. So if that's, you have a WooCommerce installation that you wanna show the latest item that's on sale or something like that, things like that. So we're gonna show a demo of that in a little bit. But the biggest thing for voice is that it lets customers and users access data in a different format than your web interface. So this is double-edged sword in a lot of ways. For one, it makes your content much more accessible for users who either can't consume it in the standard web interface for one reason or another or just aren't used to that. A couple of weeks back we were having a conversation with somebody who was telling us how she was always trying to get her grandfather to text with her back and forth. And he never wanted to, he didn't understand the interface. And then he got Siri on his iPhone and he started dictating to Siri and she would text his granddaughter and they were able to text now. And that's just kind of an example of a voice interface enabling interaction with content. That's slightly different than somebody reading published content, but this is a different interface that some people are just more comfortable with or more able to use. On the flip side to that, when you're serving up content on a browser on the desktop or whatever, you can present users with a lot of options. So you can say, okay, yeah, here's our 10 latest articles, here's a list of our most popular categories, here's all that stuff. When anyone who's been through a phone tree has had this experience where you get a list of 20 options and after you read through all 20 you realize the second one probably applied to you, but you don't remember what that was and so you have to have them go back and read the list again. Voice is really powerful for a user asking a question and getting one answer. So if you're trying to provide the same sort of interface through voice as you do on the web, it's not gonna work as well or be as effective. So just something to think about when designing these kind of interfaces is basically, you want the user to be able to ask a question and get an answer, so say, give me the latest post from the site or what was the top headline yesterday or the top three headlines yesterday? And you can construct these conversations, so if I asked what were the top three headlines yesterday, Alexa could respond here, the top three headlines. Would you like to learn more? And you can kind of have this back and forth and store state in a conversation a little bit. The tooling's getting better around that, but the primary interface we see right now is one question to one answer, which is why people like it for search as well because you don't have to look through that whole page of Google search results, you can just get one answer back. So Amazon and Google both kind of have these standard formats for skills, which is basically the voice version of apps that they think everyone needs. So Flash Briefings is a good example and relevant to a lot of publishers. Flash Briefings basically let you expose your content to users in a way that they can add you as a news provider. And then when you ask Alexa, what's in the news? Here's your Flash Briefing. In Wall Street Journal Minute Briefing. So for example, I've added Wall Street Journal as a news provider to my Flash Briefing. I've done a mixed course Thursday for the major challenges. Stop. Thank you. So that was pre-recorded, obviously, they can submit MP3s into a feed that then Alexa can download and play for you. You can also have your post content just read off by the computer-generated voice. And so, where are my alley folks here? Anybody still around? They might be out in the hall. They've created this plugin called VoiceWP, which brings a lot of the work of creating these skills into WP Admin. So you can do a lot of that setup and choose what feeds you want to go out and expose to different users. Right in WordPress, which is really pretty cool. So if that's something you're interested in, definitely find them later today or tomorrow and chat with them about that. But what we've been working on is you can also, like we said, create completely custom endpoints, which you can map to completely custom skills. So up there in GitHub, we have an example of that and that's what we're gonna walk through right now. So pretty much how this works, you kind of just saw the exchange. For a custom skill though, I would speak the command. The command would get heard and then sent to the cloud and turned basically into a big JSON blob. So that separates out what does Amazon think I'm trying to ask for? What are any key words? So if I say, is it going to rain on Thursday? It would determine that I was asking for weather and it would pick out Thursday as a keyword. And then it passes all of that to, in this case, a Lambda function, which is just a serverless piece of Python that only spins up and runs when it gets an input. That piece of Python code then just says, okay, we need Thursday as important and he's asking about the weather, so I need to call this specific API endpoint to get the weather data for Thursday. Or in our case, the quote of the day, which we're gonna be looking at. And so it would say, okay, I need the quote of the day. I'm gonna go to my WordPress endpoint that I already have and then it gets that JSON data back. Lambda takes it and formats it into a response that the echo can understand. And then the echo speaks that output back to the user. So if you do something like a flash briefing or a different type of skill, there's the Lambda and the WordPress steps basically get cut out of this flow because Amazon takes care of it for you. But if you're doing it custom, there's a couple more steps. And again, you can see the code for both the Lambda stuff and the custom WordPress endpoint, but that GitHub link. So let's take a look at it. We've got here our WordPress site. And I have so many tabs open. And what I've done is basically just created a relatively straightforward custom field that's our quote of the day. Make that a little bigger for y'all. So this is just the setting in general settings. And we've also created a REST API endpoint that exposes this quote of the day. So then once you have that set up and you have Amazon looking to WordPress at that REST endpoint in particular, you can say, Alexa, ask Daily Profit, what's the quote of the day? She decided she didn't want to listen. Alexa, ask Daily Profit, what's the quote of the day? This has been a great word camp for publishers, clean and cop and hover. So we still need to help her I'm pronouncing my name a little bit, but the point is that you can, this bid state is basically being pulled live from the WordPress admin. So if we modify this a little bit and we hit save, now we've got a different quote up there. So we can say, Alexa, ask Daily Profit, what's the quote of the day? The quote of the day is, this has been a really great word camp for publishers, clean and cop and hover. So even in that, just two seconds that it takes her to parse, it's going through that entire flow and hitting our REST API and coming back with the data. So this is kind of a quick example of how you expose custom data. If you were working with some of the content endpoints that already exist, you wouldn't need to do as much on the WordPress side and you could just kind of focus on formatting that data to pass it back out to Alexa. Again, with the focus being not overwhelming your users with 45 seconds of audio coming back after they've asked a simple question. All right, another use case we've seen for this is a lot of our clients still want to do print content. They want to put out print content. And most of the time, especially with some of the legacy stuff where we come in, it's they're writing all of their content in some sort of print CMS and they're pushing it to WordPress. So this kind of goes back to what we talked earlier about WordPress kind of being the central source for your content. So in some cases, we've been able to flip that around where you write your content first in WordPress and then you can syndicate it to print. But that's been historically pretty difficult. It requires a lot of copy pasting, which is whenever we see somebody copy pasting, we try to think of how we could make that integration go a little more smoothly. So we've created basically a quick InDesign plugin that pulls WordPress post content directly into InDesign so you can drop it right into your print layouts and work with it in there. InDesign, little known fact is you can write JavaScript in InDesign. They call it JSX, but anyone who has used React knows it's not actually the JSX you're thinking of. But it's pretty cool. You can, we put together a quick script that you can basically throw up this dialogue, put in your URL for your website. It queries the post endpoint to say here's the latest 10, assuming you want one of those. But you can also then search for, if you're looking for a specific post and it kind of re-queries the list there. So this makes it really easy to quickly build print layouts without having to command tab or alt tab back and forth from your browser, copying, pasting into InDesign and then worrying about did HTML come over that I now have to parse out. And the really nice thing is if you have an InDesign file set up with what's known as character styles, so your equivalent of H1s you want always to be 28 point font and bold and whatever. If you set all that stuff up in InDesign, those mappings will actually carry over from WordPress. So we'll see that in a second. And there's more info about how you would set that up at the GitHub repo. But if you have an H1 in your content, and it comes over from the API, it's tagged as H1 and those character styles are already applied. So once you kind of set up your template, you can just go down and float WordPress content right into your layouts. And it will already match your formatting, which is pretty powerful. So let's take a look. So we've got here our lorem ipsum weekly. Seems like it's a little bit out of date, but that's, we'll have our editor update that. So basically how you do this is you select a frame of text that you want. And once you have the script installed, it appears right here in the Scripts panel to the side. If you don't have a frame selected, it'll basically tell you like, I don't know where you want me to put the content I'm about to give you. So you have to pick a frame and double click. And then it gives you this. We don't have anything running at local host at the moment. Don't let anyone tell you that typing is easy when there's 100 people watching you. Cool. So we put in the URL and we click update and it gives us these last, I think 10 or 12 posts that we saw on the front page of WordPress. So we can pick one, let's pick the second one. It also gives you the published date, if that helps you, if you have content with very similar headlines, you can narrow it down that way. And we just click insert. So we can see that this here comes in a lot bigger. It's hard to see up here at the very top, but this has been tagged with the character style head one. So this in WordPress was an H1. It stripped that HTML out and wrapped it in a character style for InDesign instead. And as far as images, it basically takes the image out, puts in kind of like a, what looks like a short code placeholder, because in a lot of cases what we found is you want to use different images for print than you do for web. So it gives you kind of that hint of like, here's what the image was called when it was living in WordPress. And maybe you want to put something else in there. So this container's a little small. There's actually more content underneath here, because it's a full front page article. This one actually. So you can see here's our content that was our H1 that actually flowed into InDesign. And then we've got our image here, which looks like it's actually broken. And then our second one here, and those are the two tags that it parsed out. So the biggest advantage of this is it just cuts off a lot of time and a lot of steps for getting your content from WordPress to InDesign. And then people who are comfortable working in WordPress can write the content in WordPress. And your print team who's comfortable working in InDesign can work in InDesign without having to worry about how the content gets between the two. So everything we covered is pretty much, people have been working with these interfaces for a while. Voice is the newest one. But the great thing about the WordPress REST API and it being as flexible as it is is that when new interfaces and new things come out, because it uses JSON, which is a reasonably agreed upon way to transmit data, there's a pretty good chance that these new interfaces can just natively parse the REST API content. Just thinking about it. So who's seen one of these? This is the Oculus Go. It is a standalone virtual reality unit that just came out a few months ago, I believe. And so it was kind of a thought experiment. I started thinking about what would happen if you could pull WordPress content into virtual reality and kind of control different aspects of VR. Virtual reality is at the core of it just content. And if WordPress is a content management system, shouldn't you be able to manage that virtual content through WordPress? So the answer is yes. Spoiler alert, I don't know if you were on the edge of your seat at all. Like we said, because most languages can read JSON, this inclusion can pretty much just happen natively, which is really cool. Again, we've kind of decoupled WordPress on the formatting, so WordPress doesn't care that it's pushing to VR versus voice versus in design. We didn't make any modifications to the REST API to support any of these demos that you've seen, aside from the one custom endpoint that we did for the voice, but we didn't have to change the content to support any of these interfaces. They all just use the native REST API. And this kind of reinforces this paradigm of really being content first and kind of developing your different front ends based on how you want to present the data. So any C-Sharp experts in the room? Cool, then the code is definitely available online for everyone to look at. And you can go check it out and take a look. Yeah, so this was my first experience with C-Sharp, which was pretty fun. But yeah, so check it out. And let's take a look. So I actually would love a volunteer from the audience who wants to come try this out. No volunteers. All right, in the back there. Yes, you sir, either one of you. Choose amongst yourselves. Who gets to come sit in the chair? Yes, give me a hand. Good to meet you. What's your name? Ryan? Ryan. All right, welcome. Gonna get you to figure it up with this here. It's not a medical device. It won't shock you, I promise. It looks very intimidating. So grab this right here. Just kind of fit the band over your head. You can help me out over there. You're gonna have a great hairstyle after this. Cool. So because this would be kind of lame if it was just him who was getting to see this, we're gonna actually take a look inside the goggles right here and see kind of what he's seeing. Cool. So y'all in the audience are seeing two different displays because VR works on a concept called retinal disparity, which is how it makes it look like you're in a real world. These images are slightly different and each of these different images are presented to each of his different eyes, which gives the illusion of depth. But we can't have depth on a flat 2D screen so we get both views. All right, hold out your hand for a second for me. All right, this is your controller. Cool. You got a trigger on the front here. How do you like that? Thumb on top, trigger on the front. Did it go off on you? Yeah. Maybe just move your head a little bit or something. Okay, so we're gonna, that's all right. We're gonna press this here and see if we can get it. There you go. Cool, so we're gonna hold this down and now you're in the VR space. So you got a little bit of cable length. You can swivel the chair around if you want. Little bit to kind of look around. So this is just like the home screen. You can customize it in space or a nighttime loft or whatever. But we're gonna actually look at a kind of loft experience. So if you look down, you can see that white dot is where your cursor's pointing. So if you wanna point your cursor down to where it says library in the bottom there and hit that trigger on the front. Cool, and then on that menu in the left where it says unknown sources, gonna click on that. There's like a five item menu to the left of all the thumbnails. The second item from the top, unknown sources, yeah. Yep, click on that. And then we're gonna click on daily profit. Yep, so this is a VR experience that we just mocked up pretty quickly. It drops you into my very fancy apartment loft. So you can look around. You can see all my platinum records that I've recorded over the years. And my nice pottery over there, I think there's a canvas. If you look all the way to your right, like towards me this way, all the way around, look a little further. There you go, yes, I'm very artistic as you can see. So the one thing I do want you to notice though is that there's a newspaper sitting on there on the table. So if you look down at that newspaper and then click the trigger on the front, it should pop up a panel right there. And if you notice, this is the first post from WordPress that we just saw. So you can click it again and put the newspaper back down on the table. You can keep playing with that if you want to. But again, this content is just pulling in from the REST API straight into virtual reality. It can pull images, it can pull text. And so if we wanted to, we could replace these platinum records on the walls with image content from WordPress or some sort of ads or something like that because it's all able to be served up over the REST API and just insert it natively into this VR experience. So thank you very much for your help. Give a big hand, everyone. Thank you, sir. So the point that we're really trying to make here is all of these interfaces are very different and all of them require their own customizations. Some of them yelling at C sharp for hours and hours. But when you control your content, you can kind of build the web you want and choose the partners that you want to share that content with because you're powered by number one WordPress and number two, the open standard of the WordPress REST API. That's the standard that we as a community should kind of unite behind. And when we do that, we can adapt the presentation to what it's good at and kind of the nuances of its interface and let the content just be the content and live in WordPress. So I'm happy to take questions and thank you very much. Hey, who's got a question? Don't be shy. In the back there or in the front here? Oh, over here. That front there was really cool. Thank you. You told me that it was really cool. So my question is very basic. What do you think or what tools do you use for API caching? Do you find it useful? Would you recommend it? For caching the API endpoints, you mean? Yeah, so definitely I think if you're expecting a lot of traffic or if you can, if you already have a caching layer on your site, you probably want to cache your endpoints as well. You can tell by the fact that we updated that thing live that these API endpoints were not cached because I'm the only traffic I was expecting on these endpoints. So I think yeah, if you're expecting a lot of traffic or if you're launching a voice interface that you know is gonna have 50,000 users or something, you're definitely gonna want to cache those endpoints. I don't have a specific solution in mind but I mean, you could just fit it into whatever you're using for caching the rest of your site. All right, thank you very much. Yeah. Other questions? I think everybody just wants to play with the... Yeah, well, so I'll be around the rest of today and I'll also be at mentoring slash contributor day tomorrow. So if you wanna jump out of a plane and do some skydiving, come find me and we can chat. Thanks everybody. We'll give it up.