@CloudExpo Authors: Liz McMillan, Elizabeth White, Pat Romanski, Kevin Benedict, Yeshim Deniz

Related Topics: @CloudExpo, Agile Computing, @DevOpsSummit

@CloudExpo: Blog Feed Post

The Utopia of API Documentation By @JKRiggins | @CloudExpo #API #Cloud

It's proven time and again how much API documentation matters to your developer experience

The Utopia of API Documentation
by Jennifer Riggins

It's proven time and again how much API documentation matters to your developer experience - in fact, it kind of matters more than anything else as to whether your API is adopted or not. And certainly developer experience matters to your overall bottom line. After all, in the world of the application programming interface or the API, developers are your users and therefore their user experience matters most.

There's no doubt your API documentation has to be sexy, but, as sexiness is in the eye of the beholder, there's a lot of debate about just what that means. Today, SmartBear sits down with Arnaud Lauret of AXA Banque (a.k.a. the API Handyman) to talk about this idea of documentation utopia and his vision of an ideal world where APIs and documentation live in perfect harmony.

The API economy will collapse on poor documentation
Before we can talk about what great documentation is, we should probably talk about what bad documentation is. The worst documentation is the one that doesn't exist. But second worst is API documentation that's never used. "Poor documentation leads to poor APIs and poor APIs lead to poor documentation-to the dark side where no one uses them," Star Wars fan Lauret said. And if your documentation isn't used, soon enough, neither will your API.

Why was your documentation overlooked? Some frequent culprits include:

  • It shouldn't have been written in the first place.
  • It's too long.
  • It's too hard to understand.
  • It's outdated.
  • It's not adapted to your audience.
  • It's not on concept.
  • It couldn't even be found.

"Without good documentation, you can't have an API and without a good API you can't have documentation," Lauret said, referring to the symbiotic relationship intrinsically linking the two.

What does documentation look like in a utopia?
According to Lauret, "API documentation should include all instructions, comments and information needed to build, maintain and use an API and [its] subsystems."

For some more or less agreed-upon qualities of good API documentation. It must be:

  • adapted for audience - like all good marketing and customer support, perhaps multiple documentation depending on the audience's needs
  • DX-first - made for humans, by humans
  • machine-readable
  • Google-readable - search engine optimization matters when most people are typing "X API" into Google
  • well-organized like a reference guide or table of contents
  • intwined with the API itself - dual-screens or opening in new window, allowing users to try something out right away
  • not a burden to create
  • with pricing and usage policies
  • with contact information
  • adapted to the learner or user
  • riddled with use cases and code examples
  • made up of everything you could need to use the API
  • paired with a story - why you are doing this to achieve that
  • easy to produce, publish and maintain
  • adapted to what kind of software is being documented, like SaaS versus platform
  • adapted to audience to the people that will use it - end user versus inside your company
  • adapted to context - when in the discovery process and how people will use it
  • equipped with some sort of way to collect user feedback on how you can further improve it
  • easily found, whether within the developer portal or prominently placed on your website

We could go on and on but instead of just making a wish list, let's get into how your documentation can make your API shine and vice versa.

"Microservices is widely adopted and the concept has been applied to documentation for usable, maintainable, reusable, replaceable micro-documentation."

Lauret says to avoid the doom of unread documentation, everything should be micronized. "Microservices is widely adopted and the concept has been applied to documentation for usable, maintainable, reusable, replaceable micro-documentation." It all falls into the domain-driven, context-driven world we're re-approaching.

And the movement toward microservices also makes documenting seem more achievable in bite-sized increments. This falls right in line with a greater sense of ownership for each service-and who better than the one who wrote the code to then explain its purpose?

Going full circle, microservices fit nicely with continuous delivery.

For continuous documentation delivery, there must be automation
While it seems like automation drives much of continuous delivery, continuous delivery has us going so fast that API documentation gets neglected. But automation can actually be the key to continually delivering great documentation.

"When you code, you don't reinvent the wheel, you reuse existing libraries and modules," Lauret said. While you still need human touch in your docs, it stands to serve that you can ease the burden of creating them by automating them and reuse-recycling them.

In Lauret's perfect APIverse-that we think we are getting nearer to every day-there will be continuous update, delivery and improvement of documentation, right along with coding and testing. This means that at least part of the documentation can and should be automated.

This automation has to come with standardization, which means that companies should prioritize creating standards for API documentation.

To offer Lauret's example: "If all your APIs are true REST APIs and you always them design them the same way, you lessen the need for documentation. If you write documentation using command and shared structures, templates, and common and shared vocabulary and concepts, they become easier to write, read, understand."

Doc automation could even have version control to pair doc versions accurately with different releases.

"And don't forget that documentation should tell stories and should get all API documentation to use them," Lauret said.

Lauret offers up probably the most popular way to automate: our very own Swagger.

"Documentation and its subjects are analyzed to check that they are consistent with each other. For example, if you have an API descriptor, the system checks that the API is conforming to that descriptor. This already exists with ReadyAPI from SmartBear. You can take an API descriptor in Swagger, and ReadyAPI will create the basic testing to check that the implementation for the API is correct compared to the API descriptor," he went onto explain.

But remember that Swagger isn't the final piece of the puzzle. It'll get down your specs and build the perimeter of your API, but Swagger alone does not make complete API documentation. Your API's story is a big part of it too. Stormpath offers a strong example of documentation enriched with a strong introduction to its concepts and terminology.

While formats like Swagger and RAML can automate the raw specification, you can also try a tool like LucyBot, to make Swagger more human-readable.

In his idyllic APIverse, Lauret sees everyone working with a documentation package manager or DPM for both people who write code and for those who write API descriptors that allow you to automate based on certain dependencies. A DPM helps you write the documentation, search for requests for comments (RFCs), templates, and vocabulary. The DPM creates a descriptor that describes the dependencies of your documentations. NodeJS is already doing something similar with its Node Package Manager (NPM), but it works for people who code, but not yet for people who write documentation. Every level of documentation is linked together via the DPM, allowing users to switch among them.

Finally, "Every single documentation is written as code-human and machine-readable. This structured document can be copied and transformed by any other format." From there, you can really start to make your API documentation-and by extension, your API- more accessible.

Approaching the world of documentation for everyone
Lauret offers the example that "If you have an API descriptor and the data are fairly simple, you can generate an API. All that without coding anything." From there you can automate even more writer-friendly documentation or even allow both your users and internal developers to make mock-ups to test if a design is good or not. From there you can build user-friendly design tools including automatic mock-ups to test if a design is good or not.

By treating documentation as code, it becomes structured and machine readable. This data then can build documentation APIs, "and, with this data, you can build outrageously beautiful visualizations," Lauret gushed.

With everything you do, you need to think about how developers are accessing your API. For first-timers, they need an intro to put it all into perspectives. There are others that will play around with your API first and use the documentation as a reference tool, wanting to easily find examples and a step-by-step of how to do something specific.

Lauret reminds you that "When your API is your product, these people need to create really cool documentation."

Like how we are teaching kids coding visually with tools like SNAP, both of these API customers would benefit from a more visual map of the API documentation, like a mind map or a flow chart, including links and ways to expand and visualize the functionalities and how they interrelate. FoxyCart's API comes with a great visualization of their API documentation. Similarly Lauret created a tree-like 3D-JS visualization of this Swagger spec to create a flow-chart view of the lengthy documentation. He's also thinking about pairing Mermaid sequence diagrams with Swagger.

All users would also both benefit from search functionality built into the docs.

Once you establish the system, structure, framework and responsibility for creating and updating API documentation, you can use that machine-readability to increase human-readability. You can create a venerable "Document Factory," a module you could integrate into a continuous delivery system, automatically generating different types of renderings from the raw source documentation, like PDFs, static websites, or even whole books.

Lauret even suggests that if your API documentation is good enough and machine-readable enough, it becomes something that could easily be converted into an API itself or as a source for partial or complete software generation. This part of utopia is already available with RESTlet and Nuclear-Powered Mushroom.

Imagine how you could better reach your developers if you can appeal to all their different learning techniques, from the person who still likes to read the code up to an auditory learner who could listen to an API-narrated walk-through, from someone who wants a stagnant image to someone who wants a Prezi-like interactive experience. You could even mimic what Absolut Vodka did with APIs, automatically piecing together audio and shots to make hundreds of recipe videos. Or maybe one day there will be a way to automate the creation of a video game that walks devs through your docs!

And it's not just user experience but languages too. Lauret shares the dream of what he class "Hyper-Documentation" where the hypermedia API meets content negotiation, where the server sends back content in a certain language or format to create truly contextual documentation.

Of course, nothing is more valuable than when documentation is integrated with its API, sort of a split-screen or hyperlinked reality where your users or potential users can jump to the part they need in the documentation and then easily toggle back to that part within the API, immediately putting to practice what they learned.

Who's in charge of writing API documentation?
The real problem with API documentation is that while we increasingly acknowledge the value of it, it's the first casualty of the "There's Never Any Time Syndrome." And when it's unclear who's in charge, you're short of volunteers too.

Lauret argues that in order to guarantee quality and audience, "only the right people write the documentation for the right audience in the right context." He contends that creating documentation is a real job for qualified people with real skills that should depend on context.

It doesn't seem to be debated that this should be a job, it more comes down to who is responsible for it. And until we decide that, I'm afraid we may find ourselves in cycle of blame game.

A trend which grows along with the importance of documentation is to treat your documentation and client libraries as products themselves. Companies like Sendgrid pair it with a product manager who has a keen understanding of the key stakeholders that has her own team of people dedicated to the task.

Some would say marketing should get involved because it's a huge tool for selling your API, as well as the aforementioned fact that SEO does matter as people are still Googling to find you first. Plus, if you're putting all this work into well-maintained documentation, you'll also need to enlist marketing or your website team to make sure you're tracking all of the doc's user behavior, time on page, and other important analytics. Only then will you know if your documentation is any good, which is to say actually used.

Like in the not-for-profit grant writing world, others would argue to outsource it to a technical writer, but I worry that an external writer won't fully understand the needs of your API user and, really, they may err on the side of too technical, not enough human. And from this technical perspective, the engineers should be involved anyway. As well as the testers for that matter. Oh and the UX folks.

I for one argue on behalf of the developer evangelist at least being in charge of coordinating this ongoing project. They're the ones who should be best aware of what the clients need and the different use cases needed to explain how to do that. And I'd argue, while they don't need to write the whole thing, they should find the right people to do it and they probably should draft the Get Started. And then the whole team should occasionally dogfood their own start docs to make sure it still makes sense and is easy to get right into.

Or why not outsource it to a brand advocate or early adopter? That customer that's working with it every day, has a stake in your API and its documentation usability, and who could use some extra cash. Her motivation may be greater than most.

Of course, it could and probably should be different roles within each company, the size of that company and perhaps even each audience using it. Add to that, is your API an ancillary product or your bread and butter? If it's the latter, then this responsibility increases dramatically. What's clear is that every company has to define the person or persons who is in charge of this essential part of the developer experience.

But it's just the beginning
We don't doubt there's a need and a demand for better API documentation and doc automation. But we're still at the very early stages of creating something that's both machine-readable and for the different audiences that could be looking to consume your API. That's where you come in.

Read the original blog entry...

More Stories By SmartBear Blog

As the leader in software quality tools for the connected world, SmartBear supports more than two million software professionals and over 25,000 organizations in 90 countries that use its products to build and deliver the world’s greatest applications. With today’s applications deploying on mobile, Web, desktop, Internet of Things (IoT) or even embedded computing platforms, the connected nature of these applications through public and private APIs presents a unique set of challenges for developers, testers and operations teams. SmartBear's software quality tools assist with code review, functional and load testing, API readiness as well as performance monitoring of these modern applications.

@CloudExpo Stories
It is ironic, but perhaps not unexpected, that many organizations who want the benefits of using an Agile approach to deliver software use a waterfall approach to adopting Agile practices: they form plans, they set milestones, and they measure progress by how many teams they have engaged. Old habits die hard, but like most waterfall software projects, most waterfall-style Agile adoption efforts fail to produce the results desired. The problem is that to get the results they want, they have to ch...
"We're focused on how to get some of the attributes that you would expect from an Amazon, Azure, Google, and doing that on-prem. We believe today that you can actually get those types of things done with certain architectures available in the market today," explained Steve Conner, VP of Sales at Cloudistics, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
Organizations planning enterprise data center consolidation and modernization projects are faced with a challenging, costly reality. Requirements to deploy modern, cloud-native applications simultaneously with traditional client/server applications are almost impossible to achieve with hardware-centric enterprise infrastructure. Compute and network infrastructure are fast moving down a software-defined path, but storage has been a laggard. Until now.
"Venafi has a platform that allows you to manage, centralize and automate the complete life cycle of keys and certificates within the organization," explained Gina Osmond, Sr. Field Marketing Manager at Venafi, in this SYS-CON.tv interview at DevOps at 19th Cloud Expo, held November 1-3, 2016, at the Santa Clara Convention Center in Santa Clara, CA.
DXWorldEXPO LLC announced today that the upcoming DXWorldEXPO | CloudEXPO New York event will feature 10 companies from Poland to participate at the "Poland Digital Transformation Pavilion" on November 12-13, 2018.
Without a clear strategy for cost control and an architecture designed with cloud services in mind, costs and operational performance can quickly get out of control. To avoid multiple architectural redesigns requires extensive thought and planning. Boundary (now part of BMC) launched a new public-facing multi-tenant high resolution monitoring service on Amazon AWS two years ago, facing challenges and learning best practices in the early days of the new service.
Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
The best way to leverage your CloudEXPO | DXWorldEXPO presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering CloudEXPO | DXWorldEXPO will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at CloudEXPO. Product announcements during our show provide your company with the most reach through our targeted audienc...
With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors!
In an era of historic innovation fueled by unprecedented access to data and technology, the low cost and risk of entering new markets has leveled the playing field for business. Today, any ambitious innovator can easily introduce a new application or product that can reinvent business models and transform the client experience. In their Day 2 Keynote at 19th Cloud Expo, Mercer Rowe, IBM Vice President of Strategic Alliances, and Raejeanne Skillern, Intel Vice President of Data Center Group and ...
More and more brands have jumped on the IoT bandwagon. We have an excess of wearables – activity trackers, smartwatches, smart glasses and sneakers, and more that track seemingly endless datapoints. However, most consumers have no idea what “IoT” means. Creating more wearables that track data shouldn't be the aim of brands; delivering meaningful, tangible relevance to their users should be. We're in a period in which the IoT pendulum is still swinging. Initially, it swung toward "smart for smart...
In his Opening Keynote at 21st Cloud Expo, John Considine, General Manager of IBM Cloud Infrastructure, led attendees through the exciting evolution of the cloud. He looked at this major disruption from the perspective of technology, business models, and what this means for enterprises of all sizes. John Considine is General Manager of Cloud Infrastructure Services at IBM. In that role he is responsible for leading IBM’s public cloud infrastructure including strategy, development, and offering m...
DXWorldEXPO LLC announced today that All in Mobile, a mobile app development company from Poland, will exhibit at the 22nd International CloudEXPO | DXWorldEXPO. All In Mobile is a mobile app development company from Poland. Since 2014, they maintain passion for developing mobile applications for enterprises and startups worldwide.
@DevOpsSummit at Cloud Expo, taking place November 12-13 in New York City, NY, is co-located with 22nd international CloudEXPO | first international DXWorldEXPO and will feature technical sessions from a rock star conference faculty and the leading industry players in the world.
In his keynote at 19th Cloud Expo, Sheng Liang, co-founder and CEO of Rancher Labs, discussed the technological advances and new business opportunities created by the rapid adoption of containers. With the success of Amazon Web Services (AWS) and various open source technologies used to build private clouds, cloud computing has become an essential component of IT strategy. However, users continue to face challenges in implementing clouds, as older technologies evolve and newer ones like Docker c...
We all know that end users experience the internet primarily with mobile devices. From an app development perspective, we know that successfully responding to the needs of mobile customers depends on rapid DevOps – failing fast, in short, until the right solution evolves in your customers' relationship to your business. Whether you’re decomposing an SOA monolith, or developing a new application cloud natively, it’s not a question of using microservices - not doing so will be a path to eventual ...
The next XaaS is CICDaaS. Why? Because CICD saves developers a huge amount of time. CD is an especially great option for projects that require multiple and frequent contributions to be integrated. But… securing CICD best practices is an emerging, essential, yet little understood practice for DevOps teams and their Cloud Service Providers. The only way to get CICD to work in a highly secure environment takes collaboration, patience and persistence. Building CICD in the cloud requires rigorous ar...
DXWorldEXPO LLC announced today that ICC-USA, a computer systems integrator and server manufacturing company focused on developing products and product appliances, will exhibit at the 22nd International CloudEXPO | DXWorldEXPO. DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City. ICC is a computer systems integrator and server manufacturing company focused on developing products and product appliances to meet a wide range of ...
Coca-Cola’s Google powered digital signage system lays the groundwork for a more valuable connection between Coke and its customers. Digital signs pair software with high-resolution displays so that a message can be changed instantly based on what the operator wants to communicate or sell. In their Day 3 Keynote at 21st Cloud Expo, Greg Chambers, Global Group Director, Digital Innovation, Coca-Cola, and Vidya Nagarajan, a Senior Product Manager at Google, discussed how from store operations and ...
Sanjeev Sharma Joins November 11-13, 2018 @DevOpsSummit at @CloudEXPO New York Faculty. Sanjeev Sharma is an internationally known DevOps and Cloud Transformation thought leader, technology executive, and author. Sanjeev's industry experience includes tenures as CTO, Technical Sales leader, and Cloud Architect leader. As an IBM Distinguished Engineer, Sanjeev is recognized at the highest levels of IBM's core of technical leaders.
We are seeing a major migration of enterprises applications to the cloud. As cloud and business use of real time applications accelerate, legacy networks are no longer able to architecturally support cloud adoption and deliver the performance and security required by highly distributed enterprises. These outdated solutions have become more costly and complicated to implement, install, manage, and maintain.SD-WAN offers unlimited capabilities for accessing the benefits of the cloud and Internet. ...