REST API Is Not Transactional

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

I was walking down the infinite hallways of Cisco Live Europe chatting with the fellow Tech Field Day Extra delegates when I probably blanked out for a minute as the weirdest of thoughts hit me: “REST API is not transactional

TL&DR: Apart from using structured data and having error codes REST API is functionally equivalent to Cisco IOS CLI from 1995

Let’s Start with an Example

Imagine you’re configuring a complex application environment on a single switch (to make it simple). You might have to configure:

  • Several routing domains (VRFs) to enable inline load balancing between them
  • A dozen segments (VLANs)
  • Subnets on those segments
  • Routing with external world
  • Microsegmentation (the unicorn previously known as reflexive ACLs)

Any one of those configuration commands could fail. You could fail to check input data and use a word as IP address, or use an impossible prefix length, or hit some configuration limits (like the number of entries in an ACL), or use duplicate names or…

If you bought the switch from the right vendor (Juniper, Arista or Cisco IOS XR) then you’d just shrug, abort the whole thing, have it automagically removed, and retry. On those same boxes you’d also be able to say now I’m done (aka commit) and have all the changes implemented at once.

On a few other boxes you could shrug and rollback to previous state (assuming you were smart enough to save it when you started).

Both options are well known to programmers dealing with transactional databases for the last 40 years… and are completely missing in REST API world (unless the API provider took great pains to implement them).

Now for REST API

Now imagine you’d deploy the same application environment in (almost) any private or public cloud, be it AWS, Azure, GCP, VMware NSX, Cisco ACI… For every object you’d have to configure (VPC, subnet, security group, routing table if you’re deploying on AWS, or tenant, bridge group, EPG, contract… if you’re working with Cisco ACI) you’d execute a REST API call. Any one of those calls might fail. Now what?

Well, you’re on your own. Hopefully you remember what you were doing and what you already created because you’ll have to clean up your own mess and you’ll have absolutely no help from the orchestration system because REST API is not transactional so there’s no rollback.

Long story short: people who claim how bad network device configuration methods are and how they’d be so much better if only the network devices would have REST API (A) might not know what they’re talking about and (B) will get exactly what they ask for. Do we really have to repeat every mistake anyone else ever made?

Latest blog posts in Network Infrastructure as Code series

4 comments:

  1. Thanks Ivan, this is quite insightful.
  2. You need to learn to get away from using CLI....says the person neck deep in millions of *lines* of python & perl *comands*
  3. When it comes to REST API over objects in a network device config, yes, your TL;DR is correct. NetConf is a bit better from that point of view.
    But, again, if you are configuring some service that spans over multiple devices, you still fall into the same trap of distributed transaction.
  4. Once again, made a similar point on twitter, but for longevity sake...

    My understanding is the headline is not accurate, but the essence of what you are saying is. Meaning, a REST API is transactional, there just is no session state saved between the transactions. You may not like the scope of the transaction, but in my understanding that is a different question.

    Again, this does not solve the problem, just hoping to agree on taxonomy, as it is important to ensure we can all communicate these complex topics.
Add comment
Sidebar