Search results

Recording of STC San Francisco presentation: Beyond mere endpoint reference — the overlooked content in API documentation

by Tom Johnson on Mar 8, 2018
categories: api-doc podcasts

I recently gave a presentation to the STC San Francisco chapter called "Beyond mere endpoint reference — the overlooked content in API documentation" on February 21, 2018. You can browse the slides and listen to the audio recording here.

Slides

Here are the slides:

Audio

Here’s the audio:

Listen here:

(Note that due to a crash with Camtasia, the screen video didn’t record.)

Event description

Here’s the presentation description:

Beyond mere endpoint reference — the overlooked content in API documentation

Most discussions about API documentation center on the reference content — the endpoints, parameters, sample requests, and responses, and so on. But actually, the reference docs make up only a fraction of the total documentation related to an API. API documentation also includes how-to topics, tutorials, and other conceptual information. In this presentation, we’ll dive into the non-reference content that is typically found in API documentation. Some of these non-reference sections include the following:

  • API Overview
  • Getting started with the API
  • Hello World tutorial
  • Authorization and authentication
  • Status and error codes
  • Rate limiting and thresholds
  • Code samples and tutorials
  • SDK and sample apps
  • Quick reference for the endpoints

Here’s a little more detail of what we’ll cover with these topics:

How-to topics. When it comes to documenting common tasks (the how-to topics in documentation), API docs pose unique challenges for technical writers. The common paradigm of providing step-by-step instructions for achieving a goal doesn’t always come so easily with APIs. The endpoints can often be used in innumerable ways and combinations to support a variety of outcomes and purposes. As such, how do you go about creating documentation around specific tasks? When the tasks involve assembling chunks of code, is step-by-step the right approach? In what scenarios would you provide the code up front followed by lengthy explanations or inline comments?

Hello World tutorials The Hello World tutorial is one of the most common topics for getting started. But this kind of tutorial varies significantly from the traditional task-based topics in regular documentation. What should a Hello World tutorial cover? What is an acceptable “Time to Hello World?” And how can you accelerate the success of this key tutorial without getting bogged down in lengthy explanations of authorization and configuration?

Sample apps and SDKs. Although most APIs are language agnostic, you often provide client SDKs in specific programming languages, such as Java or C++. A single API might have 3-4 SDKs, including implementations for Android and iOS apps. How should technical writers document these sample apps, especially when they’re in programming languages the tech writer doesn’t know? Should you document a sample app with inline code comments?

You can read the event details on the STC San Francisco site.

Location:

Workday San Francisco
160 Spear Street, Suite 1700 (between Mission and Howard)
San Francisco, CA 94105

Time: 7-8pm

About Tom Johnson

Tom Johnson

I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.

If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.