Gabe, Mateu and I just released the third RC of JSON:API 2, so time for an update! The last update is from three weeks ago.

What happened since then? In a nutshell:

Gabe, Mateu and I just released the second RC of JSON:API 2, so time for an update! The last update is from a month ago.

What happened since then? In a nutshell:

I’ve been running a lot lately, and so have been listening to lots of podcasts! Which is how I stumbled upon this great episode of the Lullabot podcast recently — embarrassingly one from over a year ago: “Talking Performance with Pantheon’s David Strauss and Josh Koenig”, with David and Josh from Pantheon and Nate Lampton from Lullabot.

(Also, I’ve been meaning to blog more, including simple responses to other blog posts!)

Interesting remarks about BigPipe

Around 49:00, they start talking about BigPipe. David made these observations around 50:22:

Mateu, Gabe and I just released the first RC of JSON API 2, so time for an update!

It’s been three months since the previous “state of JSON API” blog post, where we explained why JSON API didn’t get into Drupal 8.6 core.

What happened since then? In a nutshell:

Drupal 8’s REST API reached a next level of maturity in 8.5. In 8.6, we matured it further, added features and closed some gaps.

Drupal 8.6 was released ¹ with some significant API-First improvements!

The REST API made a big step forward with the 6th minor release of Drupal 8 — I hope you’ll like these improvements :)

Thanks to everyone who contributed!

1. File uploads! #1927648

   No more crazy per-site custom REST resource plugins, complex work-arounds or base64-encoded hacks! Safe file uploads of any size are now natively supported!

   POST /file/upload/node/article/field_hero_image?_format=json HTTP/1.1
   Content-Type: application/octet-stream
   Content-Disposition: file; filename="filename.jpg"
   [… binary file data …]

   then, after receiving a response to the above request:

Quite a few people in the Drupal community are looking forward to see the JSON API module ship with Drupal 8 core.

Because:

• they want to use it on their projects
• the Admin UI & JS Modernization Initiative needs it
• they want to see Drupal 8 ship with a more capable RESTful HTTP API
• then Drupal will have a non-NIH (Not Invented Here) API but one that follows a widely used spec
• it enables them to build progressively decoupled components
• …

So where are things at?

Timeline

Let’s start with a high-level timeline:

Two weeks ago, I stumbled upon a two-part blog post by Alex Russell, titled Effective Standards Work.

The first part (The Lay Of The Land) sets the stage. The second part (Threading the Needle) attempts to draw conclusions.

It’s worth reading if you’re interested in how Drupal is developed, or in how any consensus-driven open source project works (rather than the increasingly common “controlled by a single corporate entity” “open source”).

It’s written with empathy, modesty and honesty. It shows the struggle of somebody given the task and opportunity to help shape/improve the developer experience of many, but not necessarily the resources to make it happen. I’m grateful he posted it, because something like this is not easy to write nor publish — which he also says himself:

I’ve been drafting and re-drafting versions of this post for almost 4 years. In that time I’ve promised a dozen or more people that I had a post in process that talked about these issues, but for some of the reasons I cited at the beginning, it has never seemed a good time to hit “Publish”. To those folks, my apologies for the delay.

This is an ode to the Drupal Association.

Two big “maintainability” milestones have been hit in the past few days:

1. rest.module now is in a maintainable state

For the first time ever, the issue tracker for the rest.module Drupal core component fits on a single page: https://www.drupal.org/project/issues/drupal?component=rest.module. 48 46 open issues, of which several are close to RTBC, so that number will likely still go down. Breakdown:

• 19 of those 48 are feature requests.
• 6 are “plan” issues.
• At least 10 issues are related to “REST views” — for which we are only fixing critical bugs.
• And 12 are postponed — blocked on other subsystems usually.

(There is overlap among those breakdown bullets.)

Finally the REST module is getting to a place where it is maintainable and we’re not extinguishing whatever the current fire is! It’s been a long road, but we’re getting there!