 I guess that's the official who I am, this is who I really am. So I am a father of three, so I've got two girls and a son waiting for me in Melbourne and my wife, so I'm husband of one. As it's been announced, Codison's 12, I've been teaching programming and teaching in various aspects, helping trainers in e-learning programs for about 10 years. During that time, I've been a Moodle developer developing for the Moodle platform. I've been a developer for the Drupal platform and I've actually been developing for Drupal primarily because of the flexibility they had with their nodes and then WordPress launched with custom post types and when they launched with custom post types, that was it. I could finally put Drupal to bed and I moved over to WordPress. So I've been developing for WordPress for five that actually seems like not a lot considering how many people have been around. But my personal love of programming is the Go programming language. When I consider any kind of software being developed, I first think APIs. How can this be done with an API? So I see the world in APIs and in the talk I'm going to give you today, I'm not going to tell you how things should be done. I'm coming because I'm still learning and I'm expecting the community to push back. I'm expecting the community to help me learn more about the talk I'm about to give. So I'm a learner for life and where I want to start with is obviously APIs and starting right in the middle there with WordPress. So we all use WordPress, I assume, and we all love using WordPress but we all get to the point where we at some point have to start integrating with other services. So WordPress is not the only thing we work with anymore. We now have to integrate with other platforms, with other APIs and I'll just give you a few examples here. So you might want to integrate with Bicommerce. You might want to integrate with Cloudinary, Netflix, Bloomberg. They've got a really good API. You might want to integrate with Twitter with the Yahoo developer network and all of the APIs that they give you with Google AI and the whole bunch of stuff that Google AI gives you. There's only a few APIs but there are literally thousands and thousands of APIs. If you want to see what you can program with, visit the programmable web. There's literally thousands of APIs that we might want to interact with. Now, forgot about that one, shoot. That's also a nice little API for working with photos. Now, all of these APIs that we integrate with, they come with some challenges for us as WordPress developers but also as business owners who want to integrate with these APIs. So I'm going to list a few of the challenges that I have found as we've started to look at integrating the APIs with a few clients. Challenge number one for me is that often we work with outdated SDKs. So we need to integrate with the service. We need to integrate with the... Yeah, we need to integrate with the service. They give you the PHP SDK that we're going to use and we're going to take that SDK and we put it inside our WordPress code base. We start to work around it and realize that it's missing features that we really want to use. So that's one problem that I found. The other problem that I found is that sometimes we run into PHP compatibility issues. So it may not necessarily be an out of date in terms of the features that the other service provides us but it has certain PHP compatibility issues in there. Another issue, I want to run through these ones fast and then get to the good stuff but another issue that I have is sometimes there is no PHP SDK. So what do we do if there's no PHP SDK and we want to integrate with WordPress? Slow APIs. How many of you have integrated with certain APIs and you define that the API you're trying to integrate with has really, really slow queries and give back really, really slow results? Cross-site origin issues. Sometimes you want to build something in JavaScript. You want to use the API from JavaScript only to realize that you can't do that because the API you want to integrate with doesn't support cores nor are they intending to support cores. And this is actually where I had the idea of the middleware of the middleware plugging that in investigating a particular API, the API documentation stated in a very, very fine print only used this API with a trusted back end and then the light bulb went on. What if WordPress is that trusted back end? More on that in a bit. And then finally, every time we integrate with an API, we reinvent the wheel. So we've got teams even internally where we work, we work with one API, another team works with another API and we take different approaches as to how we integrate with those APIs. And there's got to be a way to do things better. And that's what the talk is about. Like I want to challenge us as a WordPress community, how can we do this better? I'm going to give one proposal and then I want us to consider as a community, is this going to work? Is it not going to work? If it's not going to work, do you have a counter proposal? Again, I'm not coming as the expert, but again, we start with WordPress. That's where we all start. That's for most of us, I'm assuming that's our day job if you're a developer. And how about we take all of these APIs that we work with and we start to bring a bit of order to them. So I deliberately had my first slide with all of the APIs scattered around. Now I want to start to bring them all together. I want to line them up nicely. And then once I've got them lined up, I want to connect in a standard way, I want to connect them to WordPress. So I want to introduce this idea that there is a middleware layer or a proxy that sits between WordPress and the APIs that we want to integrate with. And for us to then work with those APIs, you will integrate with the middleware layer not necessarily with those APIs directly. And I know some of you already start to think, okay, but I see issues with this. And please do, because when it's question time, I want you to present me with issues. But one of the important developments in WordPress has been the REST API. But I don't know how many of you realize that once you build custom endpoints for the WordPress REST API, it just uses regular expressions. So what if you take a regular expression and actually give it a wild card regular expression and then use that as a central point that an API query can come to and you proxy that request off to the actual API that you want to integrate with. And then having that as a proxy, there's a few powers that come with that. For one, we can start to shape the incoming requests. So request comes in and go, well, that's nice. What if I add a little bit to the request? What if I do extra things with that request before I hand it off to the API? The API then executes your request. It sends your response. When that response comes back, we can shape the outgoing response. API sends the response. We grab that. We can now modify that and extend on what the original API gives us the capability of doing. We can give it new superpowers. Another thing we can do is that in the case that we have our cause issues, now we can actually use WordPress as the trusted backend. Now I say that very loosely because it puts responsibility back on us as developers for what we're going to do in terms of exposing that API. Because having WordPress sitting as a middleware means that now all of a sudden it opens it up to me making a mistake and exposing parts of the API that should not be exposed. So we need to be careful in how we do that. The other part is that we can actually use WordPress to help improve performance of slow APIs. If we take any of the responses that come back, we can cache it. We can then look for subsequent requests that are similar and surf that data from a cache rather than serving that data directly from the API. So we can start to improve performance. Optionally, we can even now take the data that comes in and if you really want to, you can create some kind of import process and import that object as a custom post type that you can add extra metadata to that you can extend with other plugins. You can, like I said, you can essentially take one of the existing APIs and give it new features. That's kind of what I was meant to bring that one up. But yeah, so essentially we now have the ability to take a seemingly already okay API but now create other plugins that interact with that data. Extend responses, changing the way it renders, doing additional things with the APIs. We can also now have granular endpoint control. So in a case where I might want to restrict access to certain parts of the API, I can now do that. Or if I want to expose an entire API, if I'm that brave, I can do that. And one of the things, one of the key goals and why I'm giving this talk is that we can find a unified way in which we can interact and work with APIs. And we can do that the WordPress way. Now, the reason I'm saying that we can do the WordPress way is that I was actually challenged on this when I presented this and saying, but that's not the WordPress way. I was like, okay, well, what is the WordPress way? No, we have to import it as custom post types and then work with the custom post types. Do we really have to do that? If I have my middleware API and I have adequate hooks and filters in different places, wouldn't that be the WordPress way? Again, you can challenge me on that. And I've got a very simple example. In this case, I've created a middleware plugin and it's available on GitHub. I'll share the links at the end. And the middleware plugin essentially just gives me a shell. Then I create a plugin that uses the middleware plugin to register a new integration with Google Cloud Vision. And in what I've got up there, it's just a simple post. It's got an image. And what I want to do is I want Google Cloud Vision to automatically label that image. So with the plugin deactivated, nothing happens. It's just a standard WordPress post. With the plugin enabled, I've now created a settings page where I add my Google Cloud Vision API key. And once I change to save my details, I view my page and automatically it goes to Google Cloud Vision, tests the image, retrieves data from Google Cloud Vision and automatically labels my image. So that's a little example. Now I'm going to attempt to give you a live demonstration of this. So, okay, so in this case, I've got the page that has images that are not labeled. So a bunch of images that I just pulled off from Unsplash. Got all of those images there. I go to activate the plugin. So I've got the middleware plugin enabled because that's kind of required. That's what I'm basing my whole talk on is that the middleware plugin exists. Then I created another plugin that uses it. And as soon as I activate that plugin, it now gives me just one simple place where I need to put in my API key. And I give instructions for where I can find that API key or how register for that endpoint. So that's activated now. If I go back to my page and I refresh, giving that tethering works, some magic should now happen. And if I start to scroll through the images, they have been automatically labeled. So I can see that Google Cloud Vision sees the yellow. It sees that it's nature and it sees a hand. This one I thought would be an interesting challenge to see what Google Cloud Vision thinks of this one. It says it's green. It looks like lights, apparently. And it represents architecture. Globe, world, hand. This one I like, blue underwater fun. Footwear, white, black. I'm not exactly sure how it got the black, but it's close enough. This one is rather amusing. Eyewear, glasses, vision care. So it's not perfect. But the point is not how well Google analyzes images or labels them. But it's the fact that I was able to use the Google Cloud Vision API with very, very little code after the middleware plugin has already been installed. Just to show you, I'm going to get a little bit geeky. Let's just close that down and I'll go to the proxy. So this is my Google Cloud Vision integration. And all I'm doing there is adding a few filters that uses the middleware API. So I decided that I want to register it as Vision V1. So I'm going to add the proxy. I'm giving it a namespace. I'm giving it the host API, the real API that it's supposed to use, the valid methods that that API supports, so post methods. And over here, I am doing an override to make sure that responses can only come from this actual instance by using a nonce. And over here, I am adding my API key to my response. And that's my integration with Google Cloud Vision API. The rest is just application code to make sure that I find the images on the page and pass it to this endpoint so that the labels can come back. So it's a very simple illustration of what we could do. There are issues that I have not considered with this example. Authentication is one that will... I'm sure I'm going to get questions around that. I've started to think about this. I'm hoping you have solutions. But in the case of OAuth, for example, how would we handle OAuth? Would we simply use normal OAuth workflow but then save the token against the user and then use some kind of hook to retrieve that token, making sure there's got refresh tokens and everything that we need? And we're going to solve that problem. That's a problem that needs solving. So there's a few of my ideas with an example. I deliberately tried to keep that short because I want us to have a discussion. So I'm going to leave it at questions and feedback at this stage. And I hope that we have questions. I hope that we have challenges. And I hope that we have possible solutions as well. One of the interesting things that I've also found was when I started to propose this idea internally, we had other developers who were working on APIs who subsequently came up with similar ideas of how they're consuming an API. And to me, that was validation that something like this could work. But I do want us as a community to consider it. And I want as much feedback as possible. I'm not going to do a bold statement saying this should be part of core. I actually think this should not be part of core unless the community thinks that it is worth having something like that. But essentially what I have to share is this talk, proof of concept, and a reference implementation of how the middleware API works. So, questions?