Why is scripting the CLI a fragile way to automate a network?

A script that types CLI commands and reads text output depends on exact syntax and output layout, which differ between platforms and change between software versions, and it can only run one command at a time.

* Screen-scraping depends on the text layout; an API hands back named fields that stay the same across versions. *

Scripting the CLI is possible and often the first step people take. A script opens an SSH session, sends commands and then has to read the replies, which are plain text formatted for human eyes ("screen scraping"). The weak points:

• Output is not data. To find out whether an interface is up, the script has to cut the right column out of a text table, usually with regular expressions.
• Syntax and output drift. A new software version or another platform may rename a command or shift a column, and the script silently breaks or reads the wrong value.
• Sequential and slow. Commands run one after another and there is no notion of a transaction: if command 7 of 10 fails, the device is left half-configured.

APIs fix these problems at the root. They exchange structured data (JSON or XML) described by a model, so a program gets fields with names and types instead of text to parse.

Go deeper:

• RFC 3535 — IAB Network Management Workshop (2002) — operators' own list of CLI and SNMP pain points that led to NETCONF.