 Hello, and thank you all for joining today. My name is K. Adam White. You can call me Catam. I am a principal engineer in the professional services group at a company called HumanMade, a globally distributed company where we make a digital experience platform for enterprises called Altis. Altis is built around WordPress, and I met several of my current colleagues, including our director of product, Ryan and our CTO, Joe, back in the 2014-2015 range, working on an open source project together called the WordPress Rest API. I had the opportunity to work on this project as a contributor to a plugin on GitHub through 2016. And in 2016, because I was really excited about the project, I had the opportunity to speak at CSVConf v2 to leave the community with a couple of my thoughts about what was exciting about getting data access to WordPress content. I'm really, really honored to be back here again. And five years later, the hope is that we'll be able to do a bit of a retrospective. I think it's a good segue from the last talk because it's a community-led effort in that it's open source. Not quite the same in the co-making space, but there are some things that we did right, and there are some things we did wrong, and we're going to get into that today. But definitely worth clarifying that the capacity in which I'm giving this talk is, as the author of that 2016 version, as a contributor to WordPress and as the maintainer of the REST API plugin for several of the intervening years. I definitely don't speak for everyone on the project, although I have consulted with some of them. This is my opinion. So what has changed in the WordPress REST API since 2016? If you weren't familiar, WordPress is a content management system written in PHP. It's free and open source, and it powers, I think, at best guests up to maybe 40% of the navigable internet. It's hugely widespread, and we added in 2016, in October, we merged it and it got launched in December, a JSON-based data API to be able to get access to all the content in your site from applications. Since then, we've done a lot around improving our ability to define complex metadata using schemas. We've done a lot around introducing abilities to limit how much information we transmit over the wire for efficiency and economy. But the biggest thing that's changed in WordPress ever is a project called Gutenberg. Gutenberg is a block editor. It is a tool designed to blow up WordPress and have it not just be a rich text editor writing to a single field in your data days, but to give you a fast, responsive, flexible, what you see is what you get interface where you can look at each unit of your content as a block and you can compose your site using these. We started out launching it where it would let you do a much better job of authoring the content within a post much closer to one of the experiences you might have with some of the competing software out there, particularly some of the proprietary ones. But the vision is actually this year, we're expanding that and we're doing what we call full site editing where you should be able to adjust anything on your site using the block editor, including sidebars, headers, et cetera. To build a project like this, we needed an API and it was built on top of the API that I was here five years ago to talk about. So this has been an extremely exciting voyage into the future for WordPress. And I think that this is the project that has made WordPress something that is viable to continue being relevant for years to come. It's 18 years old, but I think it's only becoming more powerful as a tool for publishing on the web and actually also for structuring your own data if you wish to use it as a data store of any sort. So what have we learned since then? The first thing was that if I look back on my talk from 2016, I was saying, we want data access to our content. It'll be revolutionary, I swear. We didn't actually have a really compelling argument why. We were coming at this from this perspective. We were saying, obviously we need WordPress data API. It would be so great if we had one. We can do all these cool things. We'll have flying cars, we'll have new editing interfaces. We can do machine learning. And what we realized as we were challenged on this was that we were in fact so blind to any argument that this couldn't be a good thing, that we were sort of beginning to look at anyone who was arguing against it in a negative light and in the honor of it being May the 4th, we were really just hoping that we could merge the darn thing, have a giant party and then move on and not worry about it for years. I'll come back to the overextended Star Wars metaphor later. But Helen Hosandi, the lead developer of WordPress 4.7, the release lead who was in charge of saying, yes, you get to put this in or no, you don't. She challenged us and called us on her bullshit and said, who is this for? We didn't have a good answer for that. I'm sorry about that. We were not necessarily in a position where we were looking that closely on the potential use cases beyond the ones that we already had in mind. And it wasn't until we started getting the plug-in developer community on board that we were able to come to the realization that what an API provided was not just a solution to our problems because we could have continued to do those if we had left it as a plug-in but that having an API in core gave us interoperability. It gave us a foundation where all the plugins that people write for WordPress can have common expectations around how they can access and manipulate data. And one plug-in can add or adjust the data of another in the way that WordPress has always been such a strong tool. So in the end, in 2016, it did get merged, went on to power Gutenberg and we actually defined several major metrics for success. We sort of set our own bar which we didn't end up living up to in some ways but we did get that one major feature project with Gutenberg. Because the major thing that really began to demonstrate the value of the API was the Gutenberg project and that didn't launch for several versions after there was an argument of whether we should have waited whether we should have potentially merged this as a component of the Gutenberg project itself but I think that we actually did benefit from the co-creation aspect where an API contract is a standard and the standards are best when they are challenged from a variety of perspectives. I think that the downside to having done something like the REST API as a part of Gutenberg would have been that it would make it too tailored to that particular editor use case and some of the reader or other app integration use cases that we were considering might not have been as possible as they were. I actually consider it to be a major success that we were able to launch with as little change to the editor as we did. Like we have, sorry, to the API in order to build the editor as we did. So the one area where we know we definitely made a misstep powers Gutenberg, that's fine, this doesn't impact it but if we want to go beyond where we are now we never considered versioning to be a core construct of the API that we were building. The plugin we called V1, it used to V1 in the URL the new infrastructure all in the WordPress core uses WPV2 in the URLs for these endpoints because they're all communicated over HTTP and that constant isn't really accounted for anywhere else. We didn't give ourselves the ability to progressively and gradually update the version the way that we might have been able to if we'd followed a path more like, for example I think Stripe does this very well with their API. One thing that did impact Gutenberg around the generation of the API was around user capabilities. And this is another area where we considered the resources in a WordPress site like a post, an article, a media item to be kind of holistic entities but WordPress, the reason plugins are possible is because there's a variety of seams throughout the application where you can insert, adjust, remove or filter data. And that includes the capabilities that a user has. There could be users where based on custom code they only have access to a certain site on a certain post on the site. And we work at Humanmade with a number of very large enterprise clients where they have either very tightly rigorously controls media outlets or in some cases banks and financial institutions where there are regulatory requirements where not every user is going to have access to everything, even within the same item. And this question of who can access an individual field in our API who can modify an individual field was not something that we really accounted for. We just had the sense that either you had access to the poster you didn't. This is the one sort of most technical bit I'll dive in here but we adapted JSON Hyperschema's target schema property to be able to communicate actions that were available on a resource. And then when we're editing it we expose what the currently authenticated user is able to do in the links property. It feels very bolted on and it feels like we were not aware of at the time how the flexibility of our data was going to be limited by the degree of control we had over who was able to access it. I think that something that I've learned about data from this project far beyond WordPress is that there is always a complexity to what type of user has access to different actions. And I think that I'm still interested in figuring out whether there's a better way to solve these problems if we do eventually ends up solving that version issue and launch a V3 in some fashion. In addition to providing access to specific fields on responses we also took a really long time to support authentication from external applications. In the spirit of an API only being as good as what you can do with it when we launched the REST API in WordPress would only let you authenticate responses from a logged in browser session using a cookie and not system. We had plugins for various other types of authentication but they didn't actually meet... What's the phrase? Cut the mustard for a variety of reasons in terms of things we could merge into core. They either had insufficient or non-existent documentation many of them didn't have a lot of good example code. These are the things that you need to really make an authentication system usable but I think that many of them were closer than we realized. Unfortunately, I think that it's probably on me as the steward of the project up through about 2019 that I kept saying, no, I don't think we should do this authentication thing. I think we should do something better. And I let the lack of a really compelling system with good documentation and good user support hold us back from getting something that was broadly applicable into core. Gutenberg can operate within the admin. The authentication system we had in place was fine for that but it doesn't work for the mobile apps, the iOS and Android mobile apps. It doesn't work for a node script. It doesn't work for any sort of external tool or sort of a software service central external application and by saying that we had to wait for someone to bequeath us a fully documented, fully user example, authored plugin that we could then merge, I was setting an impossibly high bar for actually getting something out the door. I want to give full props to Timothy Jacobs, the current lead of the component and George Stefanis who helped drive through an application password solution built around basic auth that launched in December of last year. So if you've been waiting since 2016 to write an app that integrates with WordPress, now is a really good time to finally get on that but I do think that it was a mistake that we took that long. And unfortunately, one of the reasons why I think I dragged my heels on a lot of these things and why I feel like I personally have held the project back to some extent is around burnout. And this is the last major thing I want to get into but we were all extraordinarily optimistic about this project in 2016. All of us, the lead developers on the project, Ryan McHugh, Rachel Baker, Joe Hoyle and Daniel Bakuber were putting in so much effort. We had over a hundred individual contributors in the plug-in stage, we've had even more sense. There was so much effort to get it into core that when we met with challenges, not the good one like Helen Pose, but when we met with skepticism about it, we just pushed harder. And I think that we got a lot of particular pushback from Matt Mullenwick, the co-founder of WordPress and the CEO of Automatic and whichrunswordpress.com. He is the benevolent dictator for life of the WordPress project. The buck stops with him on decision-making and I still don't fully understand all of his arguments against the API, but during the proposal stage and even long since, there's been a lot of talk over why is this useful? I feel like most of us who were involved in the projects and all of the plug-in developers who rallied around it to help make the case for it being merged saw the potential of what went on to become Gutenberg, what went on to become these other systems. But this sense that we were fighting uphill when coupled with the I think very reasonable criticism that the release lead Helen was leveling against us, it at least for some of us, encouraged a bit of a us versus them attitude. And I think that in open source, coming at things from the perspective of being a heroic underdog is both extremely tantalizing but also really harmful. If we think about- Five minute warning. Yep, I'm on it. I know I'm running a little late, but I'm almost done. If we think about storytelling, it's easier to tell a story about underdogs. Going back to Star Wars, they had to make them the underdogs again when they rebooted the trilogy in 2015. But that's not a successful model for collaboration on an open source project. I think that the success we've really seen around the REST API is when we've reduced this and we've been able to have folks like Timothy drive the development of this without the baggage of having participated in that merge discussion. And we've also had the developers of Gutenberg take ownership of their components and bring that lens of we need this for our core WordPress tasks of this block editor but can we make this endpoint broadly usable? That type of thinking has taken hold in the project's contributor team. And that's getting us through this but I definitely call myself out for getting to a point where I was feeling frustrated which accelerated the actual sort of normal open source contributor burnout that I experienced but I'd also call out a little bit folks like Matt who continue to say, oh, I don't know if we need it or I don't think it should have been merged long after it had been because that made it much harder for us to continue to bring in new contributors. And if you don't have a continual stream of new contributors, over time everyone changes focus unless they've made a business out of something and an open source project really depends on not just having a low barrier to entry in order to get started but also having components that people can feel excited about and negative talk about a critical piece of software by the lead of that software makes it hard to rally the troops around getting people excited to continue making it better. To avoid ending on a bad note, I will say again that even though most of us that worked on the plugin have taken a bit of a step back we have seen a lot of success in this it does continue to be a very solid foundation. And I think it will be complimented by other types of API that might be introduced in the future like GraphQL. I see those very much as meeting different concerns and both being relevant going forward. And broadly speaking, it has definitely been worth it because the fact that we've made these APIs for problems that we experienced and for the block editor has had an interesting curb cutting effect around making it easier to get started using WordPress data at all. The previous API to the one that we built was XMLRPC. It was really unwieldy to deal with. And so by replacing it with JSON we were making something that was easier for us to write codes interface with. But it's also easier to understand. And as Ashley from Boston University called out at a conference a number of years ago, this has had the effect of making it easier for anybody to get involved doing data things with WordPress. And that I continue to be really excited about. In summary, what have we learned about data? We need to know why having a standard matters we need to be able to articulate that clearly if you're going to sway a large community project like this. We need to plan for versioning. We need to understand that you need to be able to have access to data and know what level of access you have within any object for it to be really useful. It's never us versus them and for you an open source community. And doing things right is going to have repercussions beyond what we expected. Thank you.