Open emrikol opened 8 years ago
@emrikol Hi. I'm Tim Dunham from USA Today. I work with Ephraim Gregor. He suggested I work on this issue. I see that a REST API transport layer exists for the old version of the REST API. Are we going to appropriate that file and rewrite it to use the "new" REST API, or is there some reason to keep the existing one and create a different file? Sorry to ask such a simple question, but I'd rather not start off by messing things up.
Hi @timdunhamusat!
The "old" REST API functionality was specifically built for the WordPress.com REST API. Our plan moving forward is to use the core WordPress (.org) REST API.
I've unfortunately done a lot of looking to see how much of the current code could be rewritten to use the core REST API, but if it could be reused it would be a great time saver :)
Hopefully that answered your question. If not, or if you have others, please let me know.
Thanks!
Hi @emrikol and @philipjohn,
I'm about to start working on this. I have two initial questions:
1) Should the REST API implementation support PUSH and PULL transport, or just PUSH? 2) What types of authentication should this support. Currently, from what I understand, only cookie based authentication is supported in the .org REST API (which wouldn't work for us). Are we going to rely on the user to have an OAuth plugin enabled or one of the other authentication methods/plugins? I'm of course disregarding basic auth which is not encourage for production.
Thanks! Matt
We also need to make sure that the existing REST PUSH client works with WordPress.com first.
For any WP REST API endpoints let's stick to OAuth for now.
Also cc @joshbetz for any thoughts.
The primary transport layer out of the box should be WP REST API.
This would also include implementing any necessary authentication support for a "push" transport.