Add support for WP-API /wp-json endpoints.

[timmyc]

This PR is part of the project to integrate the WP-API with the WordPress.com API. WP-API endpoints will utilize the following endpoint structure on WordPress.com:

/wp-json/{ site }/{ namespace }/{ version }/{ endpoint }

For example a "core" endpoint for post types would be:

/wp-json/{ site }/wp/v2/types

There has been some discussion about this URL structure ( and some of its oddities ) already, and here is a quick synopsis that @nylen provided:

- /wp-json is the default URL prefix for all REST URLs in core: rest_url_prefix. Everything that uses core’s REST scaffolding has this URL prefix and I think it is best to use the default.
- We need to add /sites/%s because we want to serve requests for all sites from a single domain, rather than from each site’s domain like WP-API does by default.
- wp/v2 is the WP-API namespace for the core endpoints. So far there’s also oembed/1.0. Plugins can add their own namespaces – I imagine we’ll have wpcom/v2 or similar for WPCOM-specific endpoints like store. More info in the WP-API discovery docs.
- Then finally the path to the endpoint itself like/posts or /types.

With the version being further down the path, the other libraries like wpcom.js will need to be aware of how to properly build the paths depending on API version as well - this PR just adjusts the base path to be ready for WP-API v2 endpoints.

/cc @retrofox

[retrofox]

small question by the way:

We need to add /sites/%s because we want to serve requests for all sites from a single domain, rather than from each site’s domain.

So the parameter into the url always will be a domain and It never will be a site id?

[retrofox]

Can we add a simple example here ? Do we have already defined some endpoint working for that?
Just let me know if I can you.

[retrofox]

Anyway LGTM

[timmyc]

@retrofox my plan is to try and build out an endpoint in wpcom.js to utilize this - so that could serve as an example. There still is a bit of chatter/discussion around the path - so it could change still - though so many things are already in motion it might not change.

So the parameter into the url always will be a domain and It never will be a site id?

I'm fairly certain slug/ID will be interchangeable here - but will verify

[retrofox]

@retrofox my plan is to try and build out an endpoint in wpcom.js to utilize this - so that could serve as an example. There still is a bit of chatter/discussion around the path - so it could change still - though so many things are already in motion it might not change.

👍

What do you think to apply these changes in wpcom-proxy-request handler as well?

[timmyc]

What do you think to apply these changes in wpcom-proxy-request handler as well?

So far the path logic for apiVersioning for the proxy is done in the rest-proxy js itself - there is a diff on wpcom going for that change currently.

[retrofox]

oh cool. Thanks!

El jue., 11 feb. 2016 a las 19:41, Timmy Crawford (notifications@github.com)
escribió:

What do you think to apply these changes in wpcom-proxy-request handler as
well?

So far the path logic for apiVersioning for the proxy is done in the
rest-proxy js itself - there is a diff on wpcom going for that change
currently.

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

[retrofox]

So far the path logic for apiVersioning for the proxy is done in the rest-proxy js itself - there is a diff on wpcom going for that change currently.

oh, nice. Thanks!