Your feedback on the WP REST API

Earlier today, I tweeted:

Right about now seems like a good time to get official feedback on WP REST API from @wordpress’s lead developers and committers. Just sayin’

Helen, a lead WordPress developer, replied with:

Where does this feedback go, how is it structured, what makes it “official”, and how binding is anything that is said?

To which I replied:

maybe: 1) make/core or personal blog posts 2) I have suggestions 3) comes from your voice 4) actual goal: build consensus

There’s a lot of background to this exchange. If it doesn’t make sense to you, first read this WP Tavern post and then read this Post Status post. The tldr: we’re at a juncture for the WP REST API (a good thing!) where we’ve completed a ton of work (four years for Ryan, in fact) and need to make decisions on whether it’s ready to be merged, or needs additional work before merge consideration.

And we need to make these decisions as a group. Of individuals. With very different: backgrounds, opinions, experience levels with the REST API, and experience levels with other APIs. I’m sure you all know how group decision making goes.

Before we make decisions though, it would be incredibly helpful to have as much information on the table as possible — so everyone can know all sides of the decisions we need to make. This is why I publicly requested “official” feedback on the WP REST API from the WordPress project’s lead and contributing developers:

The feedback doesn’t need to be of any particular form. Jeremy Felt already posted his, which is A+, very much appreciate. And, we (Ryan, Rachel, Joe and I) would love constructive feedback from anyone and everyone — but WordPress’ lead developers and committers are the ones who will be maintaining this project for the long term.

If you’re looking for inspiration on how to get started, I typically try to frame my feedback as:

• What I like.
• What I’d like to see improved.

Both of these could cover:

• What you like about the features the REST API supports, and which features you think are a priority to add before merge (and after).
• Of our documentation, what topics you find explained well, and which should we focus our efforts to improve upon.
• Of our codebase, what abstractions and patterns you find delightful, and which you think are confusing.
• What you like about how we’ve conducted the project so far, and what changes you think we need make for the next six months to be successful, and the twelve months after that.

Ultimately, “should we merge it?” is a binary decision. But, getting as many perspectives as possible out in the open will help us better explore the potential ramifications of the decision, which is more important than the decision itself.

If you don’t want to post on your personal blog, then leaving a comment on this post is a great place for your feedback. Thanks in advance!