In general, an application programming interface (API) specifies how some software components should interact with each other. It is a structured specification. Because of this it is not intended to be used manually. The CLI or the GUI are, most of the times, a frontend to this API. Some people call the CLI an API, but this is not correct. Most CLI’s are too unstructured and are intended to be interactive, and thus be used manually.
I couldn’t agree more with Ivan on the incompetence of GUI’s, especially when it comes to examples like configuring OSPF, and for power-users. However, there is a group of users in the operations department that need the guidance of a GUI, the need a GUI wizard.
What the casual network admins need are GUI wizards – a tool that helps you achieve a goal while keeping your involvement to a minimum. For example: “I need IP routing between these three boxes. Go do it!” should translate into “Configure OSPF in area 0 on all transit interfaces.” When you see a GUI offering this level of abstraction please let me know.
We at NetYCE have built tooling to do exactly this. The architects and engineers make an abstraction of the network and model topologies and services. They create automation scenarios that can be operated by casual network admins. It is not an expert system, so “Configure OSPF in area 0 on all transit interfaces” has to be modeled by engineers, but once modeled it can be used again and again.
Of course this kind of automation is best to be used with repetitive tasks. Configuring OSPF is not one of them, but delivering end-to-end layer 2/3 VPN-services with VLAN’s and MPLS combined certainly is.