WP Tavern › Forums › Create Topic
Joe Hoyle It’s not yet clear whether WordPress contributors will dig in and push for inclusion of the endpoints against Mullenweg’s recommendation or whether they will opt to spend more time polishing the existing endpoints. In my opinion, this is not the choice on the table. For the record, the REST API Team support further iteration on the existing endpoints before being merged into core. That could mean waiting for the WordPress.com API team to use those endpoints in production, or gathering more usage feedback from others. I am strongly against merging anything before it’s been well-proven and well-tested. The proposal by the team was to include the 4 content endpoints when they are ready. We had a lengthly overview as to the progress of those endpoints, more details on what we feel is left to be done can be seen at https://github.com/wp-api/wp-api/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.0 Why these endpoints specifically? Because they are do-dependent for the most part. Shipping Posts without support for Taxonomies would not be that useful. Going for development of _all_ functionality (somewhere around 8-10 total data routes) should not be underestimated. It’s taken somewhere around a year and a half to get the current 4 to where they are now, and that was with 2 years prior art from Version 1. As someone who has been in the weeds of that implementation for a while now, I cannot over over-stress just how tricky trying to retrofit a consistent, coherent interface on 13 years of organically grown code and ideas can become. I’m looking forward to being part of the writing the implementation for the remaining (and majority) of functionality, however I don’t want to stop users and developers benefitting from what is already being built for another [several] years. One fairly large caveat here to address, probably: I don’t believe that implementing other endpoints (such as Plugins, Themes, Multisite, etc) will have any meaning full impact on the design of the Posts, Terms, Users and Comments endpoints that we already have. Therefore, I don’t see a good reason to not roll in endpoints as they are determined to be ready, in isolation. This may be where the disagreement lies. I think there is a very high bar for “ready”, which is why the team is not proposing that we merge _now_, there is still work to be done, but we feel what we have is getting very close.
Joe Hoyle
It’s not yet clear whether WordPress contributors will dig in and push for inclusion of the endpoints against Mullenweg’s recommendation or whether they will opt to spend more time polishing the existing endpoints.
In my opinion, this is not the choice on the table. For the record, the REST API Team support further iteration on the existing endpoints before being merged into core. That could mean waiting for the WordPress.com API team to use those endpoints in production, or gathering more usage feedback from others. I am strongly against merging anything before it’s been well-proven and well-tested.
The proposal by the team was to include the 4 content endpoints when they are ready. We had a lengthly overview as to the progress of those endpoints, more details on what we feel is left to be done can be seen at https://github.com/wp-api/wp-api/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.0
Why these endpoints specifically? Because they are do-dependent for the most part. Shipping Posts without support for Taxonomies would not be that useful.
Going for development of _all_ functionality (somewhere around 8-10 total data routes) should not be underestimated. It’s taken somewhere around a year and a half to get the current 4 to where they are now, and that was with 2 years prior art from Version 1.
As someone who has been in the weeds of that implementation for a while now, I cannot over over-stress just how tricky trying to retrofit a consistent, coherent interface on 13 years of organically grown code and ideas can become. I’m looking forward to being part of the writing the implementation for the remaining (and majority) of functionality, however I don’t want to stop users and developers benefitting from what is already being built for another [several] years.
One fairly large caveat here to address, probably: I don’t believe that implementing other endpoints (such as Plugins, Themes, Multisite, etc) will have any meaning full impact on the design of the Posts, Terms, Users and Comments endpoints that we already have. Therefore, I don’t see a good reason to not roll in endpoints as they are determined to be ready, in isolation. This may be where the disagreement lies.
I think there is a very high bar for “ready”, which is why the team is not proposing that we merge _now_, there is still work to be done, but we feel what we have is getting very close.
Name *
Email *
Website:
Topic Title (Maximum Length: 80):
Forum: — No forum —AI and WordPress Articles Blocks Showcase Discussions Events Introductions Jobs and Working in WordPress Podcast Episodes Site and Block Editor
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
Email Address
Submit
Enter the destination URL
Or link to existing content
