Thanks to everyone who made it to the meeting today. Here’s what we discussed.

Authentication
We’re aiming for OAuth 1.0a in core by version 1.0. Max Rice has an implementation in WooCommerce’s new API (based on WP API) that is pretty lightweight, so I’m happy to include something like that in core.

I’d like to aim for OAuth integration in 0.8 (next week’s release), and smooth it out as needed in 0.9 and 1.0.

OAuth might make development use harder, so basic authentication will likely stay around, but probably moved into a separate plugin for development use. For Javascript applications, an OAuth access token will be pre-issued via wp-api.js, and we’ll have to bake signing into that too. This shouldn’t be too much of a problem, fingers crossed.

Having API clients opens us up to cool things like client scope, however we’re going to look at this after 1.0 once the core part of this is complete. We also have to consider the WordPress apps for various platforms, so we may need to look at more things here.

Global State
At the moment, the various sub-parts of WP API (e.g. WP_API_Posts) rely on a bunch of global state via actions/filters. This could make it a pain for plugins to use the WP_JSON_Server class without modifying it. We talked about this, and it’s probably not as big of an issue as I expected, but I’ll get up a pull request about this soon.

Request/Response Objects
At the moment, all request parts are passed in via function parameters (yay!) but not all values are returned from the function (boo!); that is, our methods cause side-effects. Headers for example are sent via the server object, which makes it difficult to embed responses from endpoints into others without accidentally sending headers as well.

This is something that needs core team discussion as well, but the feeling here is that we want to push towards this, based on usage patterns both in this project and in others. I’ll begin talking about this with the core team to gauge their feelings on it, and we’ll see what everyone thinks of it.