Some unsolicited feedback for the Fields project from my time with the REST API project

Capturing advice I left for the sands of time.

  1. Set a clear mission statement for the project. This will give clarity to the problem you’re solving, what to say yes to, and what to say no to. You ideally want to avoid crises of faith late in the project.
  2. For your contributors, clarify involvement expectations. When most contributors are doing so in their “free” time (e.g. not getting paid directly for it), it’s really difficult to budget for unlimited development scope. A little bit of proper project management goes a long way. I feel like WP-API is a much more sustainable project with four contributing developers than two. I would encourage you to have at least three.
  3. Model your data before writing code. What is a field? What attributes should it have and why? What is a control? What attributes should it have and why? When you dive into development before appropriately modeling your application, you run into these implementation details one by one, and burn a lot of time (waiting to) discuss them.
  4. Focus on clearing blockers above all else. Because you’re working on an open source project with contributors across many timezones, average time to feedback will optimistically be 6 hours. More likely, it will be 24-48 hours. This slow feedback cycle can kill progress on pull requests. As a project maintainer, prioritize giving feedback, clearing blockers, and making decisions.

Thoughts on using WP-API for WordPress-based apps

This past week, I got to do my first client project using WP-API. The scope of the project is to create custom endpoints for a WordPress-based web application. The endpoints will eventually be used to power iOS and Android apps.

I thought I’d use the opportunity to gauge usability of using it in a project. My feedback is from the perspective of a developer needing to create custom endpoints for WordPress — I haven’t written any client-facing code yet.

These notes are roughly edited. Mostly I just want to get them up before WCSF.

What I like

WP-API has a comfortable implementation of using WP_Error for returning error responses in my endpoint callbacks. Being able to specify the HTTP status code is a great touch.

Extending WP-API’s core classes is really nice for DRY. They should be designed to be extended — I’d suggest they’ll be more commonly extended than used standalone.

For instance, I was able to get a lot of mileage out of extending WP_JSON_CustomPostType and customizing the response values for prepare_post(). However, I basically reset the original array (because the project has different data models), so it would be cool if there was some reusability there.

Also, I was able to easily add an authentication check for get_posts(). But, I wasn’t able bypass delete_post()’s capability check, so I needed to create my own.

Context argument is proving to be easily reusable. I invented my own context that seemed to fit in the paradigm.

Route registry is pretty much copy and paste == it works. I love the style of route definition too: /(?P<id>d+)

What can be improved

Using bitmask operators to map HTTP methods to callback isn’t terribly intuitive, although it’s easy enough to get going by copy and paste. I’ve never liked that part of the Rewrite API, and don’t think we should repeat it.

It would be nice to be able to modify the “data” field associated with a WP_Error entry. I’ve set up my models to return WP_Errors, but then I need to recreate that error in my controller to include the status code.

Because we have a variety of content models that are often mixed and mashed (e.g. a Post displayed with Author, Terms, and “Featured Image” Attachment), we should do embedded media really well. I think this is lacking in WP-API right now — you basically need to reinvent the wheel on each endpoint.

I’ve spent way too much time writing code to define and validate supplied arguments. I know this is something I like and Ryan hates, but it would be cool if we could nail field definition and validation for endpoints. This is something we did with H-API. It seems like we’re part of the way there by using Reflection for argument definition in our endpoint callbacks. Easy type validation is just the next step — maybe it could be introduced as an optional library.

On that note too, using Reflection against the defined method arguments to decide which request arguments are passed is too magical. It’s new to PHP and will be completely baffling to Joe Shmo WordPress developer.