Before the rise of graphical interfaces and flashy user desktops, the Command Line Interface (CLI) was the only way to interact with a computer. But the retro CLI is making a comeback.

It’s a basic form of computing — the CLI accepts text commands and interprets them into functions on the operating system. Due to its developer appeal and scripting capabilities, the CLI has become a vital element to cloud computing management, but more and more API-related companies are beginning to offer a CLI on the side of their API as well.

In this article, we’ll explore some CLIs in the wild to track its reappearance within the SaaS platform stack. We’ll see how companies like Zapier, Curity, Amazon, and more are releasing CLIs alongside their API offerings to maximize their platform usage and better cater to the wants of their developers. Some API-related companies may realize that offering a CLI could improve their third-party developer experience.

CLI vs API: What’s the Difference?

Whereas CLIs are meant to be human-readable, APIs are programmed into applications.

Whereas typical users rely on an interactive Graphical User Interface (GUI) on their devices, a Command Line Interface (CLI) is another route to the same end. A CLI is the barebones text-driven command line to access the operating system; A user enters text input, awaits a response from the machine, and so forth to complete actions.

Yet, it’s still relatively human-readable in comparison to an Application Programming Interface (API), which is a highly flexible instrument for building tools. Whereas APIs make it possible to build and connect applications in a machine-machine sense, a CLI is arguably better for ad hoc tasks or quick exploratory operations since it is more human-readable. Where an API integration may be overkill, the CLI is well-poised for quick one time changes and non-repeating tasks.

Advanced computer users often prefer the command line interface as it provides the most powerful means to control an operating system, and allows for automations with scripting. If launched from a command line shell, many normal programs allow further manipulation from within a CLI too. Some applications may even support both a API, CLI, and a GUI, or be run by CLI commands wrapped in a GUI.

As the CLI is a direct, visual, human-readable doorway to interact with a system, it makes sense that a CLI could be the most direct, human-readable doorway to a company’s data, services, and functionalities.

While that privilege has been regulated to web APIs in recent years, the Command Line Interface is making a resurgence as many companies turn to it to allow nuanced control offer a consumer’s cloud data and processing. For example, Google Cloud offers a Cloud Shell to manipulate cloud resources directly from a web browser that simulates a Linux shell.

In many cases, an Application Programming Interface drives the CLI and GUI. As Ivan Pepelnjak notes:

“Newer platforms commonly use the same API exposed to the end-user to implement their CLI and GUI.”

He concludes that though a CLI may be easier for humans, an API is easier for machines. With a CLI, you can easily enter commands (given the proper syntax) to visually see the response, whereas API integrations are built into applications and the result is often seen within the third party application. A recent Cisco group discussion seemed to reveal that APIs and CLIs can happily coexist as they excel at complementary functions.

Cloud Computing Relies on the CLI

To understand the utility of the CLI one needs not look farther than cloud computing. For interacting with virtual machines, spinning up instances, running applications in the cloud, arbitrating a virtual datacenter, and more, a CLI is a developer favorite method to initiate cloud transactions.

Let’s zoom in on some important CLIs to understand their unique approaches, and to get a picture of how CLIs are aiding software providers and consumers.

Amazon Web Services (AWS) CLI

When we talk about CLIs being used in cloud architecture, AWS is inevitably going to come up. Amazon’s vast spectrum of web services undoubtedly relies on many types of offerings to cater to various users, and AWS is a prime example of a company offering a single command line tool to better interact with these cloud resources.

Running on Mac OSX, Windows, or Linux, the AWS CLI can be used to explore instances, view S3 bucket contents, manage buckets, and more. The aws-shell gives some assistance to CLI users, like autocompletion and in-line documentation — helpful usability boosts.

As this AWS:re talk demonstrates, a good AWS shell script is typically less than 100 lines of code, and is run in sequences with simple domain logic. Using a CLI in this manner is vital for automation, unlocking some big continuous integration potential.

Having crafted API definitions for 66 Amazon Web Services, API Evangelist notes that Amazon does a good job of putting equal emphasis on both their CLI and API mission:

“I think the relationship between CLI and API isn’t discussed enough in the API sector but is something that is clearly strong across the AWS ecosystem.”

Would-be CLI providers should take a page out of the Amazonian handbook — avoid documentation inconsistencies and ensure all available pathways to functionality (GUI, API, or CLI) are equally supported.

Google Cloud CLI

From cloud computing to storage, machine learning, security, and more, Google Cloud provides a wide array of tools to help build applications. The unique trait here is that Google Cloud Shell offers a command line interface to manage these cloud applications, as well as all Google APIs, from within any web browser.

The Google Cloud Shell comes flavored with built-in helpers like Bash and emacs, and comes with support for many major programming languages. With it, you can do things like configure Kubernetes projects from the command line.

CLI-like command behaviors also exist within the Google Cloud SDK. For example, the gcloud CLI’s beta service-management provides command-line functions to create or manage APIs, such as converting a Swagger definition into a Google specification.

Though some actions are still in beta, this strong momentum toward placing continuous integration tasks in the command line could enable application and API developers to manage their dependencies in an easier way. On top of that, using a browser-based Cloud Shell could be convenient as it eliminates the need to store a local SDK, and helps divert issues of differing OS’s during team collaboration.

Zapier CLI

Zapier recently announced a CLI as a new means to create integrations directly from the command line, allowing developers to deploy integrations even quicker than before.

“Some of a developer’s most powerful tools call the command line home”

Using the CLI, developers can connect to 750 tools. Whereas the CLI is more for long-term usage catering to JavaScript users, allowing developers to write an app in JavaSCript, test, and handle migrations, and more, they also offer a Web Builder GUI for non-developers.

“This CLI tool is a new, powerful way to plug into Zapier’s ecosystem. You can write, test, and deploy your own Node JS apps directly from your machine.”

Zapier noticed how their customers work in environments like git and source control scenarios, and built a tool catered to that similar usability. A lot can be said for attentive companies like that who listen and respond to the needs of their audience.

Since they also offer a Web Builder, Zapier’s tool catalogue caters to users of all backgrounds, hopefully widening the funnel to garner more interest in the platform. One potential downside is that there is no Web Builder/CLI parity — as of writing, CLI apps can’t be converted into Web Builder apps, and vice-versa.

Curity CLI

Masters of the OAuth spec, Curity.io has developed an innovative Identity Server that APIs and mobile apps can use for highly secure logins. Since the server is designed for DevOps, managing the platform can be done in automated ways using scripting to work with custom workflows. For many developers, that’s where “CLI” comes in.

As Jacob Ideskog described to Nordic APIs, the Curity CLI is 100% model driven, meaning everything the configuration model contains is available to configure within the CLI. The Curity CLI is made in a Juniper style, which affords a more consistent model where elements are well defined in a tree structure. It is also transactional, which means the CLI configuration doesn’t change dramatically every time you hit ‘enter.’

It appears that Curity has put much forethought into design and consistency across the entire platform model when building their CLI.

Apiary CLI

The API design stack Apiary can be used to prototype and test APIs, and privileges the API Blueprint approach to design and documentation. Using the Apiary CLI, developers can work locally to develop and preview their APIs, and update documents on Apiary.io. What’s cool about this is that developers could write their entire API documentation from the command line. The success of the Apiary CLI could indicate whether or not other API management tooling may want to sneak its way into the command line.

Heroku CLI

Heroku is another cloud platform developers can use to build, manage and deploy applications. The Heroku CLI wraps the Heroku Platform API so developers can create and manage apps from within the terminal. Something unique is that Heroku provides plugin capabilities so that developers can customize the CLI experience.

A heroku help command returns an extensive help menu of possible commands, and their step-by-step documentation on CLI usage is eye candy for developers of all levels.

Wercker CLI

Wercker is another contender in the growing world of CI tooling. The Wercker CLI exists within the Wercker platform, which integrates with Kubernetes, AWS, Google Cloud, and team collaboration channels. From the Wercker command line, teams can manage containers and perform orchestration commands. What is unique with this offering is the ability to plug in multiple services into this third party command line shell.

Kong CLI

Kong is an API layer or gateway that RESTful API providers can use to manage their APIs, handling things like rate limiting, authentication, caching, and more. In addition to a RESTful API for administration functionalities, they also provide a CLI to manage Kong instances.

BrightWork CLI

Brightwork.io offers a platform to build and host microservices. Since using the Brightwork API is pivotal to the application deployment workflow, they’ve centered their offering around a CLI to better server developers. The nice thing is that this is Node.js package is easily downloadable from a terminal.

To build an app, you run a bw init command to create a YAML manifest. After editing that file, developers login with user credentials, create an API key, and use it to interact with the Brightwork API.

WordPress CLI

The community-maintained WP-CLI focuses on automating the tedious WordPress installation and plugin update process. Commands such as wp plugin install or wp plugin activate transcribe many of WordPress’s administrative functions into a terminal environment for quick, simple control.

This novel approach eliminates the need for managing site architecture from within a web browser, a mainstay for most CMSs. One could easily see this being extrapolated to cover other common WordPress functions, like user management, tagging, article publishing, and more. Though this isn’t an officially supported interface, it demonstrates another potential use case for novel command line tools.

Other Notable CLIs

Our list of CLIs for SaaS products certainly doesn’t end there. Azure recently released a v2.0 of their CLI for helping configure cloud services built to model a Linux environment, IBM Connect offers a CLI to help manage configurations, and there are also CLIs available for APImatic, Cloud Foundry, Rackspace, Oracle, Digital Ocean, and many many others.

Best Practices for Offering a CLI

Now that we’ve evidenced a growing trend of CLI support across the industry, what best practices are there for maintaining one?

Juniper vs Cisco: Compare the two main CLI style families, and see which works best for you. Ideskog favors the Juniper style for its structure, consistency, and well-defined elements.

Design it to be transactional: As Ideskog notes, “this is VERY important. When you work in a CLI you need to be able to prepare your configuration, validate it, compare it with what you have, and then in the end commit (apply) it in one single step.”

Clearly separate operational and configuration data: Operational data are things like statistics and uptime, and are dissimilar from configuration such as ports and hosts. The differentiation should be obvious in the design. Ideskog warns to never allow configuration to depend on operational state:

“An example is an interface that can only be configured if it’s connected to the Internet. This means that the configuration may have been valid when the admin set it the first time, but when internet connection goes down, what do you do then? The configuration is suddenly invalid. This is a bad property of a system. It makes it very hard to pre-provision a system, since you cannot tell beforehand if the configuration is valid or not.”

Let the model drive the CLI for ultimate consistency: For Amazon, in order to reach a consistent command line experience across thousands of commands, they did the following:

“We decided to auto-generate commands and options from the underlying models that describe AWS APIs. This strategy has enabled us to deliver timely support for new AWS services and API updates with a consistent style of commands.”

Shoot for CLI-API-GUI parity: If you follow a model-driven paradigm, every single CLI command should be accessible as an API call, and vice versa. As API Evangelists notes, the AWS API and CLI are pretty much in sync in terms of functionalities:

“Making sure there is parity and consistency between what is available via a UI, and the API and CLI is important.”

Be careful about evolvability, especially when updating. Command documentation, API docs, and functionality must remain in sync. As Jeff Browning said:

“CLIs are hardwired scripts that work well in the short term but don’t evolve as gracefully as true integration”

Adam DuVander of Zapier lists some great CLI best practices in his article here, some of which are summarized below.

• Provide a help screen: Usability and discovery are very important for CLIs. Make accessing a Getting Started guide easy with simple flags like -h or ?
• Offer tab completion.
• Steal from the champions. Replicate patterns from Linux commands that work, and take advantage of succinct commands.
• Offer customization options.
• Make security a high priority.
• If desktop-based, support different OSs and developer environments so that no teammate is left in the lurch.

Benefits to Offering A CLI (Alongside an API)

More and more API providers are supporting a CLI alongside their API. But why? Here are some top reasons on why you may want to provide a CLI alongside an API offering:

Whether it is making a human readable interface to better appeal to developer tastes, automating tedious UI actions, or offering new scripting capabilities to accelerate your continuous delivery, a CLI could amount to time reduction for users. It could also could negate the need for SDKs if browser-based.

But the key proponent to adopting a CLI is that it keeps developers where they work. Since most developers work from their favorite editor within the command line anyways, offering this ability keeps them where they are most comfortable.

Final Thoughts: Is CLI-First the New API-First?

A CLI is a powerful ally for improving developer experience, as it could be used in an interactive mode to debug, troubleshoot, or explore in real time, or used in a high-level, abstracted way with shell scripts to unite local and CLI actions.

We covered the uses cases for CLIs in cloud computing, but also found emerging CLI support among other sectors; API gateway layers like Mashape’s Kong, identity specialists like Curity.io, documentation generators like Apiary, CMSs like WordPress, and micro-app integrators like Zapier are all spearheading CLIs to offer nuanced controls.

Since a quality designed CLI is based on an API, going “CLI-first” won’t likely replace the “API-first” mantra. However, it’s a significant component within the arsenal of third-party integration options. In gauging if it’s a right fit, platform architects should view their offerings from a large perspective to see if a gap exists between their programmatic devices and more visually appealing interfaces.

There are many companies implementing both an API and CLI, but did we leave off any shining examples? Do you have any best practices for reaching API-CLI parity? Please mention below!