 The client came to me asking for me to build a website, a back end to ask, a back end for the mobile API and point services, and then also the mobile app. Of course, me thinking that, I'm like, oh great, this is like the perfect client ever. Little did I know that client wasn't overachiever, meaning that once I gave them the price for all of that, they slowly back to the point where they stopped answering my calls. But then that led me to this question of why did it cost me so much to do all that? Because I had to think about what was coming to mind. I had to build a CMS for the website that she can use and manage her own content by herself. And then I had to build a back end for the API endpoints, which in my head, I'm thinking, okay, Eva's going to be in Laravel, Ruby on Rails, or Node.js. And then the mobile app, which of course I'm going to use PhoneGap for just because I love PhoneGap. And then, all that is keeping in mind is how can I, one fuck came to me, how can I conciliate that into the smallest piece possible? And that's when I discovered the WordPress JSON API. So what's great as it does, it gives us a way to access our information through a very round of sources without any additional development time, which gives us a streamlined effort. First thing I'm going to talk about is, continuing that, what we're going to discuss today is a quick overview of JSON. I wasn't expecting everyone to be familiar with Fedora, so bear with that little quick section on it. If you will, just, okay, we're going to sift through that one. And then from there, we're going to go on the RESTful best practices and core security stuff, and just how you should develop your RESTful API endpoints. And then from there, we're going to actually talk about it, and then the plug-in, and then we're going to get into actually how you can start selling it and using it in your daily routine as far as the developers. First things first, an API primer. Now JSON, that stands for JavaScript Object Notation. It's pretty much a way to think of a data, a client-side data handling that works, that looks exactly like a JavaScript object oriented notation. It uses key value pairs, and you can, there's no real formatting to it. You can, if you want it, you can say like first name as the value key, and then value whatever you want, or you can just put a random string in it. It accepts numbers, strings, objects, and arrays. So you can have a little flexibility with how you want to actually send off your information to the next person if you're building it. And of course, one of the greatest places of JSON is JSONP. It allows client-side communication between cross-domain. So if I'm on a domain on server one and domain on server two, contacting domain one will only be called a function of success handling. Make sense, everybody? Okay, moving off from that one. And here's just a simple example of JSON, looks very nice, clean, not at all like XML if anyone's from me if that was in the dark ages. All right, now RESTful. REST stands for Representational State Transfer. What it is is a code architecture style format that's been widely accepted. It has the best practices for setting up your own API services. The way it works is pretty much simple as far as structure goes. It takes into mind all the ACP requests for correct operations, as it's based as far as just create, read, update, and delete. And it has authentication methods like basic and O-off if any of you ever tried to use user information, log in like from Twitter, or Facebook, or Google Plus, or whatever social media platform, maybe even Pinterest. And that's kind of, you're already familiar with that part. Now, best practices, of course, like anything, best best practice is involved in development. You wanna make sure that the base level has it's own, it's similar throughout whatever your API endpoints are. So whatever it's resources, WordPress JSON, which is the fault of the plugin we're talking about today. Whatever it is, it has to be that same base level, cuz that most makes it scalable. And by scalable it means that no matter at certain points, you may start off at the beginning with maybe one or two endpoints, but it also keeps in mind availability for you to grow into like maybe a hundred depending on what type of client or application you're trying to build here. And of course, for security reasons, you have to use an SSL. Whenever you're making a post, if you don't have an SSL certificate on it, anyone can see your information, whether it be a user, passwords, certain credentials like credit card information, whatever it may be anything, anything secure that you don't want to expose, has to be over SSL. Moving on. Now, using the WordPress API. Now, this section is gonna be a quick primer of setting it up and getting into it. Now, I know it's not gonna be too detailed, but that's why we're gonna leave more of that into the actual discussion for the end of this, okay? Now, the setup is pretty simple. You either go to repo on GitHub and download it, include it into your plugins folder, or you can just download directly from the plugins repo in your WordPress admin. And from there, of course, you activate it, and then once you activate it, it's already default Europe base setup for you. And if you want, you can hit that URL with the basic generic post, just to get a git request of all the list of posts that you have, and then you're done. You see it, you have a beautiful, big JSON file of all your posts, depending on if it's pagination or not, a very thing you've done recently. Now, you might be asking, okay, that's great, and it has a ton of features. Of course, the WordPress JSON API has stuff like, hey, I can make a post, I can edit a post, I can create a post, or I can add a meet attachment, or say, whatever else is general, I can do in the WordPress admin just for a JSON API endpoint. But how do that make that better? How do I extend on that? How can I make that my own? And that's where this JSON API plugin really shines, because it is truly extensible in a familiar way that any WordPress developer can easily get form-wed with. If you look currently on the board right now, you'll see that what I'm doing is adding fields from ACF to my response. Because natively, metadata does not return an JSON WordPress API, so you have to make that call. I know everyone here is, I know no one's just trying to be that guy who doesn't like the most popular thing, right? So everyone loves ACF, right? Awesome. Yeah, whatever it's like, any type of metadata, whatever it's plugins from ACF or just in general, you can always want to make sure that you hook into the filter to make sure your iSpeak gets accessible in case this doesn't default what you need. Moving on, another way to extend it is by creating your own endpoint. So say you have a certain post type or certain user, certain set of information that you want, that you need separated from it. This is the perfect way to do it. As you can see here, it's pretty much the same. Instead of I have filters that add action to the WordPress JSON server before a serve call. And of course, all this documentation on what actions and what filters and which hooks you need to go into are available in the WordPress API documentation. So as we can see here, going back to the code on the white, the board right now, this is initially just an initializer for the code, for the post type that I already set up inside of my example class right there. You can see it on the required ones. And then from there, it's just registering your filters and then it's adding it to the WordPress JSON API file itself. And here is where we're actually making our routes. So to make a route first, you have to of course declare a base and then what type is going to be for whatever information you're trying to pass on through. And then you register it. It's pretty straightforward to the point where you can get it without actually meaning to dig too deep into the documentation. So always keep that in mind. Now, the most important part of my talk, how can you sell it? Of course, we're all developers here. We can all Google some code, figure out a plugin, figure out, hey, I can figure out these some, why am I coming to this talk? You come here because you wanna learn how to sell it and get into your corporate everyday life. Now, one of the few things that any developer here can honestly say is they've always had that one client who as soon as you hand off the keys to your WordPress site, they break everything and give you that call in middle of the night or sometime awkward timing saying, hey, I don't know what I did. I just updated this plugin or hey, I'm doing the CMS. I'm adding this code here and there and it's not working for me. So raise the shot, show of hands how many people would love to have their interface that they built for themselves, for their clients, that they cannot do anything except edit posts, edit data and they know you wouldn't be able to break anything. I think everyone should have their hand up right now. Well, luckily for you with the WordPress API, you can do that. What this allows you to do is say, I know the previous talk here was on Backbone, so say if you wanna build a single page application that hooks up to your own services as far as clients go. If you have certain user credentials, give them a user password and information and then from there, they can log into it and they can access their own stuff through your system. That way, they don't have to worry about serving maintenance. You never have to get that five o'clock call saying, hey, my Bluehost account's just suddenly crashed. What do I do? And you're saying it's like, call Bluehost? You don't get those calls anymore and it's always safe and secure and you know for a fact that whatever they do is not gonna break anything that you build. Another thing that I'm most happy about is that it can power mobile apps. I said earlier, I'm bigging in a hybrid mobile space and I'm really loving PhoneGap and I really love using Angular for it. And the one of the ways I've been recently trying to implement it into a certain project of mine is by giving a client a WordPress backend for their site and by using the JSON API, they can actually feed their information to the app. And then from that, not only can they populate certain static content, but they can also feed in local notifications or hit up local notifications or notifications from a server where ever it'd be information like, hey, this recurring event, like your next purchase for this event, you're about to run out of stock on this item, you need to buy it now. Or even just as far as handling all the information and data that I need on the actual enterprise level. Now, curiosity just for my sake, how many people are actually interested in building mobile apps right now? I feel like this side is always raising their hands and you guys are just sitting there. You guys aren't interested in coding at all, are you? I kid, I kid, I kid, I kid, I kid. But yeah, so yeah, that's definitely one of the new powers and implement powers of the WordPress JSON API I can bring to you. And it involves us as a whole as community and WordPress as a web application framework. Another thing is that it can also, it's how many, if you build a plugin and you need an admin interface, you can utilize the inner admin interface for certain information and help your user streamline their interface instead of saying, hey, go to this tab, reload here, constantly refresh. I mean, we've all seen those big plugins with the tab interfaces on the admin site saying, okay, gotta click here and then here and it takes forever to load. Wouldn't that be great if it can just load like that using backbone or Angular and then just hook it up into your JSON API post? The channel data information, of course, is gonna need a server call to save or actually reload anything. But as far as this, that one bit of seamless code, I'm sorry, I love seamless so much that it just gets in my head and I cannot think of anything else. I hate wasting time. All right, now, so far as selling, we've talked about building out your own interface for your clients that you can use, mobile apps and an admin interface. Now, moving on to a little bit more topic of legacy apps. We've all actually had the work with clients that use legacy apps at some point, wherever it be, something like, we use this old .NET site, we don't feel like upgrading it, we're so used to it. It works just fine, but we love the WordPress backend. Or we have this old, I'm probably going a little bit too far here, code fusion site that just runs so amazing. Just runs so amazing, we don't want to get rid of it, right? I'm saying I'm going back, man, just let you live. By the end of the day, the West one, the problems that constantly face bigger enterprises like AT&T, the New York Times, Delta, whoever it may be. And with the WordPress JSON API, you can help them out by integrating through their current website with the points, F points. Now, curiosity, has anyone currently thinking about how they can use this instead of our daily development routine to sell it to clients? Does anyone have any ideas I have to share, get to some discussion going? No? Is it late in the day or something because no one seems excited right now? One of the things that, best idea of a distributed application where you're actually doing either with credentials or JSON fee, pretty much you have some sort of state and it goes. So when we were doing e-commerce plug-ins a few years back, this is the type of thing that we were able to get reports from the various providers. And so this is an excellent way to get business reports not from your local server, but from other sites as well if you've got in. Keep going back to cross-site resource sharing, but so yeah. No, it's definitely a great, definitely a great point. I guess if anyone didn't quite clearly understand what you were saying is, what you were saying was that as a plug-in developer with the WordPress JSON API endpoint, once it gets to the point where it's actually integrated into core, that when that happens, say all your users' information can be shared and spread across, and you can collect them into one place far as using JSON fee wherever it be on your own server, if that's what they want to do, or just throw out their own multi-site network, however it may be. That correctly summarized that to agree? Okay, cool. So if you were to set up an application, you mentioned Angular, like if you want to build an Angular application and use WordPress back in and serve up JSON, would you throw your whole application to the root of your project and put WordPress in a sub-directory, or would you, sorry, if you didn't want to have only WordPress, but say you wanted to integrate three different APIs into your single project, would you maybe have WordPress in one sub-directory and then Google API in another one, would you set it up like that, or would you set it up as a normal WordPress installation and then use your Angular app within the theme, or third option, just having it on a separate domain, you mentioned something about adding something on a separate domain? To me, it really depends on the client and the project. So say if I'm in complete control of it or I really don't, to me, it wouldn't matter as much where I put it personally, just as a preference, I would personally put it inside of the theme just so it would be easily maintainable on my co-functionality for my site as far as what's being presented to the live right now is in one place. But depending on the client, to say I may have a client that has a once, this actually goes back to a funny story about a previous client I had, they had a mobile application which only ran on iPads, and from there we had to figure out a way of displaying information from a system, beforehand it was all raw JSON files. And with the WordPress JSON API I came up with a solution, whereas I can just set up, stand up a site for them, hand it off to them, get those API endpoints set up, and that way they can just constantly update whenever they want, instead of me having to package up something weekly on every Friday at five. So does that answer your question in general or is it? Little bit, but I can basically take it depending on the client's situation. Yeah, of course, I mean at the end of the day, every situation depends on what you're trying to purpose is and what issue you're trying to solve. I can definitely see a situation where as I would want my regular project separated from my WordPress instance just because it's not truly interrelated to anything I'm doing at that point. But at the same time, I can also see it going inside of it. Next question? You know, was this the point you were talking about when you were in here for the previous talk? The back bone talk? Yeah. No, it wasn't. So one guy mentioned the JSON API, this is the one you go into the core. This is, because what, OK. So they're both called the same thing. It's just JSON? I thought REST was in one of them, because he kept saying REST. It's the JSON REST API. WP JSON REST API. OK, just wanted to make sure. Just make sure. There's a plus in any of the other API, it just calls it. REST API, yeah. OK. And it's an older plug-in that's similar, but if you go on the funding repo and you find it, the one that's going into core, it says that one of the authors is like the REST API team. OK. So when you see that, you'll know you have a choice. Of course, the Jetpack has now got JSON API. It's one of those apps. If I just enable that, am I done? As far as getting in? Or do I need to plug it in also separately? I'm not as familiar with Jetpack's API, personally, just because I don't use Jetpack. It just says the JSON API, or JSON API. And I'm assuming all it is just loads that. It's current. OK, so I didn't use it the one from .com. There's a JSON API that's available in .com. I think that's what Jetpack is using. But that will probably change when this one is merged into core. It's likely that that one will also be updated. OK. Question. JSON API, when you use it to retrieve posts, isn't the native WordPress templating system that keeps the buttons like the edit link and read more link still working when you retrieve it? Or is it something in the data that still preserves those buttons, those links? OK, so as far as editing posts and updating posts, those are actually different action calls you can do. As far as you have your posts, I do you specify which one you want to edit, if you want to edit one. And then from that endpoint, that's where you send your information. It'll update it for you. So there's actually no buttons being passed down from as far as the data being rescinded from the server. It's from the JSON data. Does that make sense to you? Yeah. OK. Cool. Anyone else? Do you know when they might possibly be? That's a good question. Well, I mean, I know it's smooth for 4.3, right? Actually, it keeps. Are they going to start putting Meta in there? Is that going to be data? I know it's definitely a lot of bug reports have been considering putting the Post Meta inside the general response. And as far as actual core release, it's one of those things that's kind of been revolving date for a while. Initially, I read probably like last year, it was going to be 4.1. And then next thing you know, it hasn't been. And I'm still saying, OK, come on, guys. When is it going to be set a date? Yes, text alchemies are in there. It's the standard WP, DB, WP query APIs to create my own customized database query to set up my own customized endpoint. And then really, I don't care what else gets built into it automatically, right? Correct. Yeah, that's one of the great things about this. I guess I want to say, keep saying plug-in by the same time in my head. I'm thinking it's going to get in core eventually. So I shouldn't keep calling it a plug-in. But for now, I'll call it a plug-in. Future. It's the future. Yeah, the future. Let's put it that way, the future. For the future of WordPress, it's definitely one of the good points is at how extensible it is. And that allows you exposure to the hooks and methods you need to make your own endpoints instead of just binding you into the WordPress structure itself. If you're pulling all posts, are you pulling negatively? I'm sure you can set up a function to strip it out. But if you like get all posts in JSON, are you getting all post data along with that? Or just like a title and an ID or something? And then you would click through, you would get the more data? I'm just wondering, if you have a blog that has 4,000 posts or something, are you getting all that information in the single request? Oh, no. For that, it depends on your pagination setting. So you can't do pagination. Yeah, of course. Whatever your pagination settings are in the back end of your site, that's what will end up being a response. It's pretty much the same thing as just getting making a simple for loop on your index, that php, phy, your posts, however you want to do it. Very cool. Questions, questions, questions. Do you have good examples of any open source custom post type examples or anything like that that you've made? Or do you have any access to a good resource for that? Well, it depends on how you're trying to do it. As far as custom post types, how do you see it in mind? Because initially, with the WordPress JSON API natively, it supports just as long as you specify what type of post you want, it can echo out whatever custom post type you want to need. So at that point, once you make a custom endpoint, it's just for your own preference, as far as just, hey, I want this to be right here. So questions. Honestly, if I had the discussion part, it would be everyone getting excited. They'd say, count me with ideas saying, hey, we already been thinking about it. We just came out of this backbone conversation. Let's figure out how we can come up with some ideas on how to use it. It's only on camera. Don't worry about it. It's great, those things are pretty non-performing tests to check what version or to check what plugins you have installed, but potentially, you could have your own endpoint that would be like slash API slash current status, current plugin status, or plugin slash current, or something like that, or plugin slash active. And that might respond with a JSON call saying, these are the plugins that are active right now, and these are the versions that are at. And then from that, you would be able to know what you need to update or not. No, right. Jeff, that already comes with that function. Oh, I know. I'm just saying if you wanted to vote by yourself. So it sounds like you're talking about like WPCLi has an API. Sure. I would think once this gets into core, plugin authors would be able to start. A feature of a plugin would be a custom endpoint, whereas prior to that, you'd have to have some sort of dependencies as, if you've got the JSON API plugin, then my plugin will work as a custom endpoint. Or I would have to replicate my own endpoint. But if you're a plugin author, you're creating something for the central repo or something for premium distribution, once that's in core, there's a standard way that gives us all one more way to share with one another. So part of the silence you're hearing is that this is very cutting-end stuff, and it's still not quite in the mind space. But as I'm thinking about as a plugin author, I had to create my own endpoint stuff when I was writing a plugin because I couldn't count on that thing being done. And so I wrote only the things that I needed, and I ended up using the admin Ajax and localize so that I could do it that way. So I got all the functionality I wanted, but it was very specific to my plugin. And so that would also mean sharing between plugins would be less. Yes, of course, of course. I mean, once it goes back to the future, once this function is a part of the WordPress core, we can now start utilizing it. Like you said, it can be more seamless as far as saying, hey, this plugin has to implement this on API here, and then this one has to do with something here. So it will be definitely less taxing as far as just what goes on in the back end. And don't. I'll just be fighting with the names. Yeah, we already do that. It kind of started. On your slides, is that available somewhere? Yes, this slide post will be available on my website at the end of the day. Are you cool with me taking your code? Hey, go for it. Everything on this slide is publicly accessible, so whatever you want, just rip from it. Any more thoughts, anyone? Any questions? Ideas? That random idea that's tinkling your head that you think everyone's going to think you're crazy if you say it? I know there's a lot of people in there with these ideas, so just come on, say it. So essentially, I think give people, if you only wanted someone to, because we heard talk this early this morning about sort of shut down the admin and doing this and doing that. So essentially, you could have an endpoint, which is slash admin, API admin, and they could log in there and only see whatever you want them to adjust and give them KADM to you. Yes and no, what you're describing is more so building out a custom dashboard that integrates with WordPress through the API endpoints that you're building that are already set up. So say I'm a service provider who has a few five clients who I want on my service, who I think don't understand WordPress and constantly keep breaking their site, breaking everything as soon as they make one little update. So what I do to fix that would be is with the WordPress JSON API, create a service on my site as far as data handling goes and specify users for each section of the site or certain pages, wherever you want to be, or set up a multi-site network. However, you already have it set up when you're in. And then from there, use your API endpoints to connect to a dashboard that you're building separately from the WordPress instance entirely, wherever it be like. Facing it to them, so you only see posts on a WordPress and then that's what you get. It's not really, you're on the right track, but there's a little bit missing from there just because you're not, in terms of logging into WordPress, think even more so as you're building out a separate layer on a separate server, separate domain, and then just using the login callback function on the API to authenticate them to see if this person actually does belong to this site or something. So does that have to log in the API? Yes. Just connect, okay. It's information. It's either you're consuming it or you're pushing it back over to the server. It's not giving you buttons or admin interface or anything like that. So I think that's, because I've kind of heard like some of something that you might use an extra, you know, UI or some interface built into this and it's really the data exchange that's going on, not necessarily the UI can put it up, you have to go next. If you want to use Angular, if you want to use WordPress and connect to a different WordPress site and pull that data in, whatever that's up to you, just how would you do with the data, right? Correct, correct. So that's where I kind of hear a few of these things as far as like UI components being brought in. It's not that, it's, you build that with whatever tools you want to. I have a question. How long, obviously you've been using this for a little while and I honestly have been not using it because of the quick, because of the fast development cycle that's happening right now. I think it's changing and maybe I'll find a way around it or I'll build it with something else, like wearable or a rail or something. I'm really excited when it comes out. How has the changes, like as you do this project or as you do development on some of these client projects, how hard has it been to implement the changes or do you just kind of set it and then, as long as there isn't a security announcement or anything, you just kind of like it works at that point? For the most part, I've only used it on a client which were, that was a concern, was just this one client who kind of, as I mentioned at the beginning of the talk, we started on the conversation as far as the mobile projects and the mobile apps and then it kind of just fizzled out. But as far as that issue handled, I mean, it goes back into a restful best practice as far as versioning. If you notice it on Twitter, Facebook, whatever type of API endpoints, whatever API layer you're using, there's always like a version number attached to it like say api slash dot 1.0. Think Twitter's on 2.0 still right now. So as long as you version it, it works out perfectly as far as just what you need to make sure everything's working. And it also goes back unless you're going to do an end consumer facing project where maybe a plug-in or a new mobile app. Because not everyone's going to be on the latest version all the time. There's always going to be a user that's going to be on, still the beta version when you're already on 2.0. So you have to be prepared for that information and be able to process that by either properly versioning your code now or just having a constant fallback after fallback after fallback just to make sure they safety, safety can use whatever you're built for them. This particular API. Restful, basically you've got your four HTTP methods. You've got your put, post, get, and delete. And you've mentioned it, CRUD. Now there's two ways of mapping to CRUD. There's what they call the naive method and then the quote unquote proper method. The naive method is usually good enough. Do you have a one to one mapping between CRUD and the four API methods or do they, or does it matter of implementation in the backend point? Where are those choices made? As far as information goes for the most part on the WordPress JSON API, it's all already built for you and there's documentation for that on their site currently. But as far as extending it goes, that's 100% up to you as far as how you want your personal stuff structured. The only thing that's good, as far as naming conventions and how you want, as far as responses and how you want that to be handled. Are you specifying at the CRUD level or are you specifying it? That's at the HPTP method level. Okay. My reference to CRUD earlier was just as an expectation of, hey, this is what RESTful does. This is how it represents, okay. I did a little bit on it maybe a few months ago as far as I had this one client who was building out this weird, it was like a weird conversation whereas they needed to segment, they're finding a different way as far as just get their legacy project integrated with the WordPress admin interface but also be able to, but they don't want their users to act as far as employees on their current site to have their use app passwords or username just because it's a safe time. So OAuth is definitely cool to use in it but it's one of those things where it can get a little tricky that help you. Yeah. Not only right now, no. A lot of projects I work for that sadly use, I've had to use this stuff before I decided I had NDA agreements on. So I could show you, but if someone ran, this is recorded. So, you know. Show anybody to have to kill you. Yeah. I don't have lawyers. Any more questions guys? Well, it's been a great time talking to you. Hope you enjoyed it. And if you want to get in touch with me, those are the methods that reach out. That's my website. That's my Twitter handle at norban.com and that's my email address. So hope you enjoy the rest of your day.