1. Bradley Kirby (@Bradley_Kirby)

    Josh Pollock on twitter regarding Matt’s objections:

    There are 2 big assumptions here – 1) That continuing to iterate in plugin is better than iterating in core. 2) That the features of the API that are proposed for 4.5 merge are going to pose a problem for core.

    I agree 100%. Matt has failed to make any coherent argument regarding the downsides of merging the API as-is. His post “Chicken and Egg” was incredibly thin compared to Ryan McCue’s “Progressive Enhancement With the WordPress REST API”.


    • Josh Pollock

      I agree with that Josh guy:)

      But seriously, just beacuse Matt is making big assumptions doesn’t mean he is wrong. I was just pointing out where I think the assumptions are.

      I don’t see how merging the current default endpoints is going to cause problems for core moving forward. I have yet to see anyone make a reasoned case for why having this developer facing feature in core is going to hurt users. On the other hand, it is easy to make the case that we will see more developers creating more cool user-facing features, if we commit to making these default routes the standard.


      • Bradley Kirby (@Bradley_Kirby)

        But seriously, just because Matt is making big assumptions doesn’t mean he is wrong.

        Agreed. Apologies for conflating your thoughts with my own conclusions. In any case, I think discussing those assumptions specifically will lead to a more productive dialog about this issue. Currently it seems like people are talking around each other.


      • KTS915

        Of course, those taking the contrary position to Matt are also making the same number of assumptions:

        1) That continuing to iterate in core is better than iterating in a plugin.

        2) That the features of the API that are proposed for 4.5 merge are not going to pose a problem for core.

        So that’s a tie.

        However, making these assumptions explicit won’t be much use if both sides seek to address them by speculating on the level of future usage. Where are the hard data?

        Oddly, the only data discussed so far were identified by Mark K and Timothy Jacobs in a short debate on a previous post on WP Tavern.

        In other words, I am not impressed by either side so far.


        • Josh Pollock

          Probably, but I don’t agree with the usage argument though. The stats for low usage in plugins are artificially low — many of my plugins didn’t make the list. But, also it’s hard to ask a plugin with established userbase to alienate their existing users who can’t upgrade to the latest WordPress version for whatever reason.


        • KTS915

          @Josh Pollock,

          I agree with you about the usage argument. Data on usage are hopeless, and should be ignored.

          What I’m looking for is data about impact on core: weight of code, impact on speed, etc, etc. as compared to the specifics of what is gained by including particular endpoints.

          In other words, I am looking for the information that would enable proper risk assessment.


  2. Nate Wright

    A point of clarification which I think you covered well but maybe isn’t that clear to people observing from the outside: no one is proposing merging “incomplete” endpoints into core.

    The distinction may seem semantic but it’s important. A single endpoint (one for reading, creating and editing posts, for instance) may be considered “complete” on its own. It doesn’t need to be accompanied by every endpoint we can think of for WordPress (eg – comments, users, site options, widgets).

    An analogy that may clarify things for those that aren’t yet familiar with the “endpoint” terminology is posts. Custom Post Types extended WordPress in important ways. But WordPress was not “incomplete” when it only had Posts and Pages.

    Likewise, when the REST API team proposes the four primary endpoints for core, they’re not suggesting a bunch of half-finished work goes into core. Even with Drew’s suggested approach, the endpoints they are proposing for merge would only be merged when they’re deemed complete by the core committers.

    So the dispute is not over whether or not to merge something incomplete. The dispute is over whether to merge none of the completed features until every potential feature is completed, or to merge completed features as they’re completed.


    • Robert Lilly

      That’s a very important point. Anything considered for merging into core must be ready for prime time. I’ve seen no valid argument to support Matt Mullenweg’s wanting to wait for all possible endpoints to be ready before merging anything. The four proposed endpoints cover a lot of what developers what to use the API for in the first place. Parity with all wp-admin features is not necessary for a minimum viable product.

      My two cents: If the proposed endpoints are merge-worthy, merge ’em. Keep everything else in the plugin.


  3. Andreas Nurbo

    Analogies are used when you don’t know how to express your thoughts in a proper manner. Just look at Jesus, no one had a clue what his parables were about and he had to constantly explain himself :D. The disciples still didn’t understand. Though in this tale are the disciples the Automatticians, the other contributors or both groups? Who knows.


  4. Peter Knight

    I don’t know what the proper route is, all I know is that I just want to see the momentum keep growing for the API.

    The idea of the ‘minimum lovable product’ is something that I’m going to be thinking about a lot now.


  5. Caspar Hübinger

    If I’m not very mistaken, the main difference of the two approaches is in marketing, isn’t it?

    WP API can be marketed as WordPress grown modern (or whatever term you prefer) to developers and decision makers even outside the community, but can it when it’s not “complete” yet? Complete in the sense you can do literally everything with it? Or in other words, would “outsiders” buy into the concept of complete endpoints instead of a complete API and consider the overall feature mature enough to work with?
    I know many agencies and developers do already, but those seem to be mainly the ones who’ve been following its development anyhow.

    On the other hand, trying to market a feature that hasn’t made it into core yet, is not marketing WordPress, it’s marketing a potential. It’s just not there yet, from an outsider’s point of view. Parts of it are in core, the rest is a darn plugin. Plugins break. Contributors can get sick. BDFLs can change their minds. Does this sound compelling from a marketing point of view?

    If I’m understanding Matt correctly, he wants to be able to take the whole cow to the market, not a couple of hoofs with a promise tagged on them. From the point of view of a project lead, I think that wish deserves consideration beyond arguments regarding development and the benefits of developers.

    Though I’m generally all for progressive enhancement, I’m not taking one or the other side here, just trying to highlight certain aspects of the problem that I think may be relevant for better understanding.


  6. fred zed

    To complete the analogy, if the current car market all have AC mag wheels and 300hp, it pretty silly to come to market with something that has none of that. Doubly so if you are trying to push it as the next great thing.

    REST API shouldn’t be included until it exceeds what we can already do through existing functions and plug-ins.


    • Andreas Nurbo

      So never then :).


      • Timothy Jacobs

        Yep, exactly :) The API is great in that it makes development easier, but since most plugin authors aren’t going to drop support for non 4.4 versions of WordPress, people are going to continue to use their own (simpler) implementations using the Rewrite API or admin-ajax.


        • alex

          Plug in authors will do it when it’s more reasonable to do so and more efficient. One of the great (and sad) things about WordPress is the relentless push forward. There are no real safe versions or safe stopping points, just a relentless move forward. The vast majority of active wordpress sites are on new versions, unless trapped by software restrictions.

          REST will come into it’s own over time if it proves to be a better way to program, a better way to develop, and stable enough for both. For the moment, it’s none of those things, and certainly doesn’t belong in core – YET.


  7. 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.


  8. Shapeshifter 3

Comments are closed.

%d bloggers like this: