Over the weekend, REST API project co-lead Ryan McCue, announced a proposal to merge the REST API with WordPress 4.7. This proposal wants to add the Content API, a selection of endpoints, to the REST API infrastructure that was included in 4.4.
Endpoints
Back in February, the team planned to merge the endpoints in 4.5, but a few core contributors including Matt Mullenweg raised concerns about the readiness of the REST API. However, core changes have been made to those endpoints and the team believes the project is now ready to be merged.
McCue’s announcement listed the proposed endpoints that include support posts, terms, users, settings, and more.
“This merge proposal represents a complete and functional Content API, providing the necessary endpoints for mobile apps and frontends, and lays the groundwork for future releases focused on providing a Management API interface for full site administration,” McCue said in the announcement. “Based on experience building on the API, we’ve polished the endpoints and expanded to support settings endpoints, which are included as the first part of the Management API.”
Authorization
The proposed merger will also include OAuth 1. According to the proposal, “With OAuth, rather than providing your password to a third-party app, you can authorize it to operate on your behalf.”
The team decided to use OAuth 1 instead of OAuth 2 because the latter requires HTTPS and WordPress core does not. McCue said they didn’t want to force WordPress to make HTTPS a requirement.
One problem with OAuth is that it requires each application to be independently registered on your site. This can lead to a lot of work for users. To combat this, the team has added broker authentication, which allows for a server, called a broker, to vouch for each of the new applications. You can even add multiple brokers.
Feedback
At the end of the proposal, McCue asked for any and all feedback. Most commenters were positive and brief, but some had concerns with the addition of OAuth 1.
Automattician George Stephanis wasn’t sure it is the best option saying, “To have to ping the third-party server for every login to check for invalidations of their applications, let alone the initial confirmation of an application … for me, it doesn’t pass the gut check.”
WordPress Developer, Dion Hulse, agreed with Stephanis, but added, “However, I feel that Application Passwords are actually a far worse solution to the problem than the various oAuth options out there, to the point that I think Application Passwords are an anti-pattern which core should never directly support. I could ramble for quite some time on the UX of these, but at the end of the day moving towards oAuth is going to provide a far better developer and user experience for API clients.”
Matt Mullenweg also shared his concerns about OAuth.
“Given the hurdles of authentication I don’t think that bringing this into core provides benefits for WP beyond what the community gets from the plugin. I don’t believe in its current state the benefit outweighs the cost, and we should err on the side of simplicity,” he said. “I am not interested in hosting the centralized brokered authentication server on WordPress.org in the 4.8 timeframe, and hesitant about the implications it has for WP more broadly. I do appreciate the thought that has been put into solving this tricky problem.”
McCue responded to the doubts saying, “While the system might seem conceptually complex, it’s pretty simple to actually implement, because the broker is just regular OAuth under the hood. The entirety of the flow can be written in 200 lines of JavaScript. OAuth 1 isn’t perfect, but everything in it is there for a reason. Is it perfect? No. But it provides a lot of benefit over Basic Auth for a relatively low cost.”
Moving Forward
After merging, the team plans to continue to make changes and update as feedback comes in. The next two projects include Management API endpoints and refining the broker authentication system. These will remain in GitHub until they are also ready to merge into core. If you have any feedback or ideas feel free to leave them in the comments of the proposal or head to the REST API meetings in the #core-restapi room on Slack.
What would you change about the Content API? Answer in the comments below.
No Comments