Complete coverage should not be a requirement for core inclusion of WordPress REST API endpoints

Photo of author
Written By Brian Krogsgard

12 thoughts on “Complete coverage should not be a requirement for core inclusion of WordPress REST API endpoints”

  1. I think you’ve argued all the points very well and clearly justified why full feature parity is almost impossible to achieve within an acceptable timeframe.

    I wonder what Matt will come back with…

  2. You’ve brilliantly communicated what those of us in the trenches of WordPress (as opposed to those of us biased by our self-interest in a minority demographic of wordpress.com users) instinctively know. The REST API team have done a fantastic and selfless job and we want these endpoints in core.

    You also didn’t need to obfuscate a weak argument with tenuous metaphors like those on the other side of the debate.

    If you’re going to blurt out opinions before you’ve fully thought through your argument (and we all do it from time to time) then you need to be capable of hearing the counter argument and putting on your big boy pants to admit that perhaps your initial thoughts were wrong. This is surely now the position Matt finds himself in.

    Oh, and Calypso doesn’t have feature parity with wp-admin. wordpress.com wp-admin maybe, but not wp-admin as the majority of us know it…

  3. “The inclusion of the WordPress REST API should be iterative, smart, and focused. It shouldn’t be all or nothing. It should be now.”

    Um. Well. Ha!

    Actually, you’ve just made the case for why it should, perhaps forever, be a plugin. If the rationale for stuffing the REST API into core is so it IS the product – new & improved, etc – and it’s not going to be that, well then what’s the new reasoning? “Because X said so…” or “Because we need a shiny new objective to rub…”?

    The simple – and smart answer – is to NOT add it to core, at least no at this time. Clearly it’s not “core” to everyone. What exactly is gained by giving more installs more (core) code than they actually need?

    WordPress is sold as a mature and world-class product with MASSIVE market share. In short, LOTS of people depend on WP. Rah rah emotional “rationalizations” don’t belong in this conversation. Please reconsider. Thx.

    • I think you misunderstood Brian’s point about . He isn’t arguing the rationale for adding theAPI to core is because it “IS the product”. He wrote that “wouldn’t be a bad thing! But it’s not the way WordPress development works”. Rather, he’s using examples of APIs that *are* the product to show how if WP development worked that way, then the API would remain a plugin for a long, long time, and that would be a bad thing.

      You seem to be arguing the API doesn’t belong in core and should always be a plugin. I suppose there’s room for legitimate disagree around that point, although I don’t see it.

      Yes, WordPress has been sold as a world-class product. But, to continue to be seen that way, it needs the API. The argument for adding the API isn’t because it’s “shiny”. It’s because of how powerful it is, and what it allows you to do with WordPress that’s never been possible before. WordPress isn’t the best choice for a lot of applications. The API dramatically opens up the possibilities of what it’s good for.

      Adding parts of the API to core as soon as they are solid, before it has complete admin functionality coverage, benefits a lot of developers (and, by extension, users), without hurting developers (and users) who won’t need it.

      Holding those features back in a plugin discourages adoption, as Brian mentioned. Committing features to core now will maximize WordPress’ benefit.

  4. I think Matt was challenging the idea that the current offering fell short of the number of endpoints he, and others, believe necessary to be remarkably useful to the greater dev community.

    As much as I want REST API in core, I don’t think that is a poor argument.

    I believe I later read (but could be wrong) that Matt said that parity (which given the current speed of development surely is unattainable in my opinion) with wp-admin should be the goal, but that what the first inclusion into core beyond API infrastructure finally includes isn’t known.

    It bothers me that passionate debate about the best way forward for WordPress so often devolves into angry rants and conspiracy theories. We all want the same thing, which is a worthwhile and reasonably solid REST API. It just may take a little longer to realize that goal than those superb project devs, and their supporters want. And they have done remarkable work on this.

    Hopefully, it will be sooner than later because my company can’t fully commit to forward compatible, stable larger app builds while the WP-REST API is a plugin. And for very good reasons I think.

  5. I know you think most people are looking to use the REST API for content and not management, I’m apparently the minority. I could care less about the content side of it, all I want is the management side of it. Until that’s implemented, not interested.

  6. This is a great post Brian, but your argument caves in on itself because of what you wrote here:

    “The remaining objects should each be feature plugins of their own, and go in over time, as they are ready, without delaying the four core objects currently under review.”

    Why does this ruin your argument?

    Because you also admit that the REST API is not complete:

    “The API is not complete, but it is ready.”

    So, to summarize your stance:

    • Incomplete things should be kept as feature plugins.
    • The REST API is an incomplete thing (and currently a feature plugin).
    • The incomplete feature that is the REST API should not remain a feature plugin.

    Do you see the inconsistency?

    Now, you might argue my points by saying that it’s okay for incomplete things to be shipped, and that the value of the REST API is such that any effort to get it into Core sooner rather than later should be made. You have done this in your article already, essentially. For the most part, you are right that it’s okay to ship incomplete things in Core. But the REST API is a different animal.

    Why is it different?

    It is the most hyped-up feature of WordPress ever, with the highest expectations placed upon it of any WordPress feature to date.

    Can you name one other feature in WordPress that has had conferences made about it before it’s even been completed? Has any other feature had so many thinkpieces, blog posts, WordCamp talks, and podcast chatter about it “changing the future of WordPress” and all of that?

    In other words, while it is often appropriate to ship incomplete things, the expectations are so high for the REST API that the “outrage” over it not being included into Core is not consistent with the expectations placed upon it.

    Much of the arguments seem to come down to plain old impatience.

  7. Matt’s point of wanting a complete API before inclusion into core is legit, mostly if you look at WP on the long run. It’s far better to deal with difficult unexpected problems before pushing solutions that would risk otherwise to be half baked.

    Still, I agree with the author. A complete API coverage is not realistic on any given timeline, that’s asking too much. It’s more probable that development is just abandoned or refocused on an independent fork. WordPress is famous for keeping backward compatibility, but there is a price to be paid: it’s really hard for developers to add innovative features. When systems become too complex after a long phase of incremental development, it’s time to dismantle and rebuild with a more comprehensive architecture.

    The risk for our community (if no compromise is reached) is a fork, one for the “old” WordPress and another for a headless WP data server strongly based on the API. Many like to say that WP is the operating system of the web, and its story can very well be similar to Linux distributions. There was one, they became many.

    Piero

Comments are closed.

A2 Hosting
WordPress.com