Transform your ideas into professional white papers and business plans in minutes (Get started for free)

How I Wrote a Perfect API Doc With No Code Experience

How I Wrote a Perfect API Doc With No Code Experience - Skimming Through Codebases Left Me Totally Lost

When I first started this project, I naively thought I could just skim through the codebase and quickly pick up the key information I needed to write the API documentation. Boy, was I wrong. As a non-coder with no prior experience working with APIs, the pages and pages of complex code left me completely bewildered.

I had no idea where to even begin deciphering the logic and flow of the program. The functions, variables, parameters all blended together in a massive jumble of gibberish. I struggled to identify the critical components like the endpoints, request methods, parameters, and response codes. It was like trying to read a foreign language, with no dictionary or Rosetta Stone to guide me.

The documentation scattered throughout the code provided some clues, but I still lacked the broader context to pull the pieces together into a coherent whole. I grappled with unraveling the connections between functions that spanned multiple files and folders. Tracing the trajectory of a request as it got passed between different modules proved challenging.

My lack of programming expertise was a serious handicap. I wished I had paid more attention in my computer science classes instead of dozing off in the back row. Now I was stuck trying to decipher lines like:

I had no clue what app, get, or res represented. I contemplated giving up altogether and admitting defeat. But I persevered and eventually unearthed some online resources aimed at teaching API basics to non-coders. With their help, I slowly decoded the cryptic language of code. I learned how APIs are structured, how requests are handled, and how data gets passed between client and server.

How I Wrote a Perfect API Doc With No Code Experience - Breaking Down the API Piece by Piece Was My Saving Grace

The breakthrough came when I realized I needed to compartmentalize the API into its core building blocks. Instead of trying to absorb everything at once in an overwhelming deluge, I systematically broke it down into bite-sized pieces.

I started with the endpoints, which serve as the entry points into an API. One-by-one, I mapped out each endpoint, noting details like the URL structure, HTTP request methods (GET, POST, etc), and supported parameters. Seeing the endpoints laid out separately made their distinct purposes much clearer.

Next, I dove into the request parameters, which allow customization of API calls. I documented the name, type, format, and usage of every parameter. This helped me understand how clients can tailor requests to their needs.

Then I examined the HTTP response codes, which indicate the status of API requests. Codes like 200 and 404 provide vital feedback on whether a call succeeded or failed. Documenting the appropriate codes for each endpoint eliminated guesswork.

Finally, I explored the response body structures, which contain the data returned by the API. By studying the JSON schemas for each endpoint, I grasped precisely what information would be sent back to the client.

How I Wrote a Perfect API Doc With No Code Experience - Examples Were My Guide To Understanding Responses

As I delved deeper into deciphering the API, I realized that examples were key to truly grasping how the responses worked. Staring at dry documentation alone was not enough - I needed to see the actual JSON data structures in action.

Fortunately, the developers had included some sample API calls and responses throughout the codebase. These examples proved invaluable in demystifying the abstract concepts. Seeing the real-world payloads allowed me to internalize the structure and format of the data returned by each endpoint.

For instance, when documenting the /users endpoint, the example response showed me that a typical user object contained fields like id, name, email, and created_at. This gave me a tangible mental model to work with, rather than just a vague description. I could envision how a client application might parse and utilize this information.

The examples also illuminated edge cases and error scenarios. By examining failed API calls with their associated error codes and messages, I gained a deeper understanding of the API's error handling mechanisms. This was crucial for documenting the various failure modes a client might encounter, and how to gracefully handle them.

Additionally, the examples demonstrated how to chain multiple API calls together. Many endpoints were interdependent, with one call relying on data returned from another. Tracing these relationships in the sample code unveiled the true workflow of the system. I could map out the logical flow of an application integrating this API.

Without these illustrative examples peppered throughout the documentation, I would have been left grasping at straws. The sample payloads brought the abstract API specifications to life, grounding them in tangible, real-world usage. They served as an invaluable bridge between the code and my limited programming knowledge.

How I Wrote a Perfect API Doc With No Code Experience - Avoiding Jargon Made The Doc Understandable For All

As I wrote the API documentation, I realized that using overly technical jargon could make it confusing and inaccessible to less experienced developers. While the codebase was filled with terms like “endpoints”, “payloads”, and “schemas”, I knew these words would baffle novice users. My goal was to create a doc that anyone could pick up and start learning from, regardless of their coding background.

So I made a conscious effort to avoid obscure terminology and write in simple, everyday language. I wanted my descriptions to resonate equally with hobbyist tinkerers and professional engineers alike. For example, instead of saying “the endpoint utilizes a POST request”, I would say “you can create a new user by sending data to the /users endpoint”.

I tried to explain each concept from the ground up, providing context to illuminate hazy details. To clarify parameters, I used analogies like “the name parameter functions like a label you can attach to each request”. For response codes, I said “a 404 error means the requested information could not be found, like showing up at the wrong address”.

Using more universal terms helped make the doc welcoming to readers from diverse backgrounds. I wanted to avoid alienating anyone with dense vocabulary tailored only to experts. The API should feel accessible to new learners, not like an exclusive clique.

Of course, I still included the proper technical specifications required by developers. But I endeavored to either explain these coding concepts in plain language or provide links to educational materials defining unfamiliar phrases.