Cancel

Sarah Gooding

Human Made Publishes Free WordPress REST API Whitepaper

wp-rest-api

Today Human Made released its new WordPress REST API Whitepaper, an in-depth guide to how the API is changing the way developers interact with WordPress. The publication was written for a diverse audience, including developers, agencies, project managers, and publishers. It includes a technical breakdown of how the REST API works, along with an overview of the benefits and challenges for teams that take on API-driven projects.

The whitepaper is called “Talking to 25% of the Web,” but the title may soon need to be updated as WordPress usage in mid-January is 25.7% and is forecasted to climb past 26% in Q1. It is a collaborative publication authored by the team at Human Made, which includes several lead contributors on the WP REST API team.

The overview for the whitepaper summarizes the different topics you’ll find within the content:

  • Introduces you to the headless CMS
  • Introduces you to REST
  • Provides a technical overview of the WordPress REST API
  • Explores some of the benefits of using the REST API in your project
  • Talks about some of the ways that the REST API will change WordPress development
  • Discusses some of the challenges that you may encounter in your REST API project

The 44-page guide also includes case studies of companies already using the WP REST API and a list of important resources.

“Talking to 25% of the Web” is an excellent free resource that should be required reading for anyone using WordPress, especially those who are building for the platform, consulting, creating SaaS products, or otherwise deriving their income from the software.

Human Made employs a large contingent of WP REST API team members and subsidizes much of their work on the project. The agency is heavily investing in the future of WordPress and is leading the way in helping developers learn how to build with the REST API. If you want to further your skills in this area, Human Made is also organizing an educational event called A Day of REST, which will be held on January 28, 2016. Attendees will have the opportunity to learn from the developers who are building the API as well as those who are already using it in production.

Category:
Tags: ,
11

11 responses to “Human Made Publishes Free WordPress REST API Whitepaper”

  3. What’s interesting, kinda, is:

    1) Decoupling back from front also means the back because an agnostic service / provider so to speak. That is, you can, with some work (obviously), replace your backend and keep the same front. WP (or Drupal, or Joomla, etc. for that matter) become less usique, to some extent. Is this is a case of “be careful what you wish you?” :)

    2) The white paper sez:

    “Familiar backend for authors and publishers

    One of the reasons WordPress has been so successful is that
    it provides an easy-to-understand interface for non-technical
    users”

    Well…Um…Didn’t Automattic just do their own remix of the WP backend? And isn’t one of the selling points of the REST API that front and back end are more or less things of the past. We’re decoupled on both ends. That is, a UI is a UI is a UI.

    The point being, the WP admin’s “shared experience” (read: familiarity) is, or should as promised, fade into something less and less shared (read: common, same, etc.) Yes, there are many benefits to this. No doubt.

    On the other hand, gone are the days of a biz looking for, say, a marketer with “WordPress experience” only to find out that their new hire’s previous experience (read: UI / UX in WP) have little to do with the new job. There is a real cost to onboarding and training a new employee. To date, WP had ROI appeal. It feels like that will erode as well, eh?

    —

    “Yeah, I do WordPress,” is becoming a more and more ambigious statement, is it not? Confusion, in the context of sales (read: buyer’s decision making) and/or hiring, is never a good thing. Agreed?

    From a technology POV the WP REST API is cool as f*ck, obiously :) What’s not to love if you dream in IDEs and commits :) But The Market might not be so excited about yet another shiny new object going by the name WordPress. Perhaps WP is starting to mimic the mid 90’s versions of Windows? That, ATM, didn’t work out so well :(

    Create forum topic from comment

    • But “we” aren’t “reinvent[ing] ourselves.” In fact, WordPress has, over the last couple of years, been stuffed with unnecessary cruft, and that will remain whatever is being used on the front-end.

      So then the question will inevitably become, if the new javascript-based front-end(s) are the way to go, is it really optimal to continue to try to connect them to a WordPress-based backend. I think the answer to that, at least for self-hosted WordPress sites, will increasingly be no.

      “Learn javascript deeply” is an injunction that makes sense for the reinvention (and thus preservation) of wordpress.com. It’s probably good advice more generally too. But, if heeded, I think it could well signal the long-term demise of self-hosted WordPress.

      Ironically, it’s the (in my view, rather strong) possibility that the message won’t be heeded much that will help self-hosted WP continue.

      Create forum topic from comment

      • KTS915

        You said: “But, if heeded, I think it could well signal the long-term demise of self-hosted WordPress.”

        I’ll be brief for a change…EXACTLY!

        Or at the very least, that’s not impossible to imagine.

        WP’s DNA is being an every-man / every-woman power tool. It’s confusing (to put it kindly) that the WP Elite believes the 99%’ers are both able and willing to jump waist deep into JS (in order to prop up the value of Automattic and it’s co-elite.)

        The REST API is a great idea. But strapping it to the core – both technology and product – hardly seems ideal for anyone involved. REST’ers or otherwise.

        But again, “Oooh!! Look!!!!!” is all the WP masses are fed. Few if any are pausing to ask, “What EXACTLY is this going to mean? To me? To my clients? Etc.”

        At the end of the day there is only so much high-end enterprise-esque WP dev work to go around. It’s kinda (sadly) funny how (in a way) extreme Capitalism is being wrapped in the protection of being OSS.

        It’s worth pondering: Has WP jumped the shark and become the Wall Street of the internet? Will eventually Matt M mumble, “Let them eat JavaScript?”

        LOL

        Create forum topic from comment

        • wat.

          It’s confusing (to put it kindly) that the WP Elite believes the 99%’ers are both able and willing to jump waist deep into JS

          Already there’s a split between people who make plugins and themes, and those who use them. The average user doesn’t care about the difference between PHP and JS.

          For the developers and themers out there though, I’d argue we could end up improving the situation. Rather than having to learn both PHP and JS (and the differences and similarities between them), you could get away with only learning the one language. This is especially important for tinkerers, who may be starting with modifying a plugin or theme for the first time as a gateway into programming. In addition, frontend only programmers who may only know jQuery can begin doing a huge amount extra.

          (in order to prop up the value of Automattic and it’s co-elite.)

          I’m really not sure what that’s meant to mean, but the project is not a commercial one.

          Create forum topic from comment

      • WordPress has, over the last couple of years, been stuffed with unnecessary cruft

        Having a much better external API is a great way to start avoiding this. Rather than rolling out more “cruft”, features can be developed as completely external layers instead.

        Take for example the Customiser, which some may call cruft. This could be built completely as an external application rather than being built into core.

        That said, it could continue remaining part of core (and I hope and expect it will); just because we’re adding technical abilities, doesn’t necessarily mean things will change. The possibilities it opens up can certainly help here.

        Create forum topic from comment

    • Hi Ryan. Good point.

      However, me thinks my point wasn’t clear (i.e., you missed it.) Let me try again.

      REST / Headless, for all practical technical purposes, makes solutions backend agnostic. That is, WP can be (semi) easily replaced with (for example) Drupal.

      I’m not saying that’s a bad thing. I’m simply pointing out there are plenty of other implications to all this (REST-centric) activity. Thinks have less to do with technology and more to do with product and/or experience (there of.)

      Sadly, these questions get brushed aside as everyone bows and genuflects to the technical-ness of the shiny new object. The intent is not to question the technical evolution, but to broaden the scope of the conversation, the ethics if you will, so that future (WP) devs understand what they might be getting themselves into. Maybe we too might gain a better understanding by stepping back and asking, “What if…then what?”

      Create forum topic from comment

      • I definitely didn’t miss your original point; it’s one I’ve thought about a lot.

        I actually hope that the API becomes a sort of de facto standard, with alternative implementations. A standardised open format for this sort of data on the web would be fantastic.

        However, the deeper thing here is that if people are switching away from WordPress for some alternative implementation, it’s for a reason. Whether that’s a lack of innovation, security issues, a better ecosystem, or some other reason, these are fundamentally nothing to do with the API. If WP needs to change to adapt, so be it. If we all end up switching away from WP to an alternative backend provider, that’s fine by me too.

        Create forum topic from comment

  5. As a result of using the REST API, WP can be viewed as a “glorified” database. If you look from this angle, why even use WP, and not put everything in CouchDB/MongoDB etc?
    I think that’s a real question that will come up for some (many) use cases.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.