I didn’t mean to dive into this kind of topic so early in this blog’s history, but then it just sort of happened. This post is much later than I planned, some things happened at work, and I just talked about tools for REST API documentation at a recent WriteTheDocsPDX meetup. So related issues have been on my mind for a while.

APIs need writers. And not just for documentation. Let me explain.

Earlier this year, I came across a talk at GlueCon titled “Why Your Next API Should Be Designed By a Linguist,” by Rebecca Standig of keen.io. I still have not read or listened to the whole talk, but the title alone stuck with me, and keeps coming back to haunt me. There’s a lot more to Rebecca’s argument than the kind of thing that I talk about here, but it’s part of the inspiration for this post.

I’m talking about REST APIs here, but the same points apply to any sort of programming interface. Or any sort of interface, period: CLI, GUI — ultimately they all come up against the issue of usability, or user experience. The importance of usability and user experience varies, of course, from interface to interface — who are its consumers, how can it be explained, how can information be exchanged across it.

As it happens, my first experience with usability as it relates to programming interfaces wasn’t with regard to REST, and I didn’t really know much about programming at the time. I was a mere editor of programmer documentation for a well-known platform that I won’t name here. A new version was under development, and the writer handed off a draft of the docs to me for review.

I sent back a redesign of the APIs — although at the time I didn’t quite realize that was what I was doing. But I offered a reorganization — what writers call a developmental edit — and some renaming suggestions. As I recall, it was difficult to figure out just what was supposed to happen when, and I thought that changing about some of the words could help.

It did. I wound up in a room with the writer and one of the architects for the project, and the APIs were redesigned according to my suggestions. (I prefer to think that the fact that the project never saw the light of day was unrelated to my proffered redesign.)

Fast forward several years. I’m now responsible for documenting two sets of REST APIs, one of which is planned from the start for external consumption. The other has grown out of a larger project to rewrite an entire large enterprise server product with REST APIs to support the GUI. At least, supporting the GUI was the original intent — but as I’ve been able to piece together the story, somewhere along the way the product manager thought, hey, our external customers could use these APIs too, and we could provide a much-requested enhancement to enable customized scripting against the server. (This is an on-premise server, not a public one.)

The trouble is, as we all know by now, APIs that are designed and written for internal consumption do not always match the needs of external customers, and vice versa. The reasons for the mismatch are many, and vary from API to API. Here’s what I’ve seen, though, that a writer can help with:

• Clear, consistent, sensible naming. Why inflict an endpoint called /foo_queue on any consumer of the endpoint, when /foos complies better with REST standards and doesn’t lead the customer to wonder “why a queue?”
• The analysis that leads to clear naming can also contribute to API design. Naming is potentially complicated if the resource in question is a server object. Often the client is really most interested in the object behavior, which can make it tricky to name the resource in a way that indicates both what the client/customer can expect and at the same time comply with REST standards, wherein resources are always nouns. But if you look at the problem in this way, you can also turn it on its head. (And here I suspect I may be getting a little closer to what Rebecca is talking about with respect to the intersections between linguistics and software programming.) How you design the server object itself — how you create its grammar and syntax — is deeply affected by how you think about the words you use to describe and name its components. There’s a lot more to say about this issue, but I’ll save it for another post. The main point here is that people whose job it is to describe things in words can help understand how to make the things that the words describe.
• Coherent organization. At a software design level, this is obviously related to the previous point, but I’m trying to stick to the writer part. We organize doc content around customer jobs — tasks, workflows, and supporting overview/conceptual and reference topics where applicable. This organization applies to any kind of doc, for a GUI-based product or for an API, with the caveat that the API docs are dominated by code examples, which show your developer customer what to do (instead of just telling them). But you also need reference docs, and they are harder to manage if you haven’t laid out your APIs in a thoughtful consumable order, especially if you’re generating docs from your code annotations/comments/docstrings.

Some product teams that develop APIs explicitly include writers as part of the core team. I worked this way briefly, and my co-presenter at WriteTheDocsPDX does now, at Salesforce.com. It’s good for the docs, obviously, but it’s also good for the product — the APIs themselves.