The project: Write a complete documentation set for a mock REST API, as the capstone for the University of Washington's API Documentation Specialization
Constraints: Self-directed, asynchronous cohort with limited peer feedback
Tech: Git/GitHub, VS Code, Markdown, OpenAPI/YAML, json-server, Vale + markdownlint, Just the Docs (Jekyll theme)
I completed this specialization as a natural extension of my Professional Technical Writing certificate. It was a way to get hands-on experience with developer tools and workflows and to practice putting my background to use in a more technical field. Our portfolio project assignment was to write documentation for a mock REST API concept developed by a classmate. I documented BookBuddy, a REST API for managing books, reading progress, and author information.
What I did
Wrote a full documentation set from an OpenAPI Specification (OAS) document: an overview topic, resource reference topics for both API resources (books and authors), a "Before you start" prerequisite topic, and two step-by-step tutorials (Get all books, Add a new author)
Defined the likely audience as library staff and added "What you'll learn" framing to each tutorial to orient less experienced users
Applied Library of Congress Genre/Form Terms as a controlled vocabulary for the API's genre field, bringing information science thinking directly into the documentation
Designed the API's rating field as a flexible, user-defined string rather than a rigid type, to accommodate different use cases
Published the full site via GitHub Pages using the Just the Docs Jekyll theme, managing the entire toolchain myself, local authoring, version control, and deployment
Diagnosed and fixed a Git branch mismatch that was blocking pushes and separately troubleshot a GitHub Pages configuration issue that was preventing the published site from updating
Why this project mattered
This project let me test something I couldn't fully know from a technical writing certificate alone: whether I could actually operate in a developer's environment, not just write about it. Working in a small, asynchronous cohort meant limited peer feedback, which was good preparation for similar real-world challenges. Persisting through unfamiliar tooling as a non-developer, and knowing when to dig in versus when to ask for help, was as much the point of this project as the finished documentation itself.
What I’d do differently
Define the audience more explicitly from the start and write to that reader consistently throughout and bring in information science thinking (controlled vocabularies, metadata) from the beginning rather than partway through. I’d also take the documentation further, from a template-based structure to fully original, audience-specific content, with every placeholder topic built out.
Index page of the Book Buddy API documentation
