New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Leverage the WordPress REST API structure for API endpoints #338

Open
ocean90 opened this Issue Mar 13, 2016 · 10 comments

Comments

5 participants
@ocean90
Member

ocean90 commented Mar 13, 2016

The current API implementation is read-only and works a bit magically. It assumes that every route needs an API endpoint too, see

$api = gp_startswith( $real_request_uri, '/'.$this->api_prefix.'/' );
.
The route handler then loads a template with the api. suffix, see
if ( $this->api && $honor_api !== false && 'no-api' !== $honor_api ) {
.

What this issue is about:

  • Remove the old API handling, announce it as a breaking change
  • Register a new route: glotpress/v1 or (gp/v1 ?)
  • Implement the same read endpoints which currently exist
  • Implement endpoints to create, delete and update all the "things"
@toolstack

This comment has been minimized.

Contributor

toolstack commented Mar 13, 2016

It assumes that every route needs an API endpoint too

Might be more accurate to to say that every route can have an API endpoint too.

I agree the current API isn't the best, I've only been marginally following the REST API progress but there does seem to be some upheaval going on with it so I don't know if it's ready for us to move to yet.

Should we deprecate the old API for a version or two and then do a V2.0.0 release to remove it?

Do we need a write API?

Do we have to consider installs that may have created their own api templates and how to support them?

@ocean90

This comment has been minimized.

Member

ocean90 commented Mar 13, 2016

Should we deprecate the old API for a version or two and then do a V2.0.0 release to remove it?

I'm fine with that idea.

Do we have to consider installs that may have created their own api templates and how to support them?

The current API templates are just doing wp_json_encode() (or are using a fancy wrapper like gp_array_of_things_to_json or gp_array_of_array_of_things_to_json). I don't think that there are installs which are doing other stuff in a "template". Seriously, a template is the wrong way for this anyway.

Do we need a write API?

Well, the current write API is a POST request to a route.
Having a REST API for all CRUD operations gives us the possibility to create single page web apps or even mobile apps (that's an interesting idea :)).

@toolstack

This comment has been minimized.

Contributor

toolstack commented Mar 13, 2016

The current API templates are just doing wp_json_encode() (or are using a fancy wrapper like gp_array_of_things_to_json or gp_array_of_array_of_things_to_json ). I don't think that there are installs which are doing other stuff in a "template". Seriously, a template is the wrong way for this anyway.

I agree and I suspect translate.w.org is probably the only site using the API in any significant way. As long as give some deprecation time I don't think it will be a problem, if someone pops up with a case where it is we can handle it then.

Do we need a write API?

Well, the current write API is a POST request to a route.
Having a REST API for all CRUD operations gives us the possibility to create single page web apps
or even mobile apps (that's an interesting idea :)).

Yep, just what we need, more work 😉.

I'd say that this would be a nice to have, not a high priority item though.

@ocean90

This comment has been minimized.

Member

ocean90 commented Mar 13, 2016

I suspect translate.w.org is probably the only site using the API in any significant way.

Heh, I'd love to use the API in a "significant way". 😄 But it's poorly performing because of missing pagination. Most of the scripts are accessing the DB directly instead…
There are also some sites which are using the /languages/$locale endpoints which we had to disable.

@markoheijnen

This comment has been minimized.

Contributor

markoheijnen commented Mar 28, 2016

Next time please inform me about it ;)

@pbearne

This comment has been minimized.

pbearne commented May 31, 2016

love to be able to hook in from an installed plugin to be able to get translation stats to encourage users to help with translations may be part of the plugins list/details page

@gedex

This comment has been minimized.

gedex commented Sep 28, 2016

Is anyone actively working on this? I'd like to help on this to replace our https://github.com/Automattic/wc-lang-packs-server and use GP API instead.

@ocean90

This comment has been minimized.

Member

ocean90 commented Sep 29, 2016

@gedex Not yet. What are you looking for? I see some routes which are specific to translate.wordpress.org. These wouldn't be part of the default API.

@gedex

This comment has been minimized.

gedex commented Sep 29, 2016

I see some routes which are specific to translate.wordpress.org. These wouldn't be part of the default API.

@ocean90 Yeah, we'll build that as another GP plugin. Having GP endpoints based on WP REST API would be the first step before that.

@ocean90

This comment has been minimized.

Member

ocean90 commented Dec 9, 2016

Related request: Include GP_Locale Data when retrieving translation sets, can re-use the ?_embed behaviour of core.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment