APIs and Writing Code — Exploring the Culinary Connection

Today, I'd like to talk about cake. And not just because I recently celebrated my son's birthday, but because it's a good way for me to think about APIs. Plus, cakes are tasty. (Though I'm from Hastings, Nebraska, originally — home of Eileen's Cookies — so I prefer a large cookie on my birthday rather than cake. Fun fact: Eileen’s used to give out 6-inch decorated cookies for Halloween!)

The Base

So, any core part of a cake is the actual cake part — the spongy, flour-based crumbtastic base. So, when you call and order a cake, the bakery is going to ask you, "White, yellow, chocolate or marble?" If they're fancy, they may offer red velvet, pink champagne, etc. But the bakery doesn't just produce cake as raw materials. They use flour, sugar, butter, eggs, milk and baking powder (plus flavoring). But we as the consumers don't really care about the ingredients. We just care that the cake is made to our specifications.

I like a good marble cake, and because I'm fancy myself, I want a three-layer, 9-inch round cake. But instead of ordering in-person (scary!) I can order online. Which gets us to the first API — CakeBase.

If we're going to turn my cake order into code, it might look something like this:

fakecakebuilder/cake/CakeBase?Flavor=Marble&Size=9inround&Layer=3

On the other side at the Fake Cake Builder Shop, they'll receive an order for a three-layer, 9-inch marble cake and will start making it immediately because they are a digital bakery, and that's how they work. Likely, in response to this, the Fake Cake Builder will send me an order number. So, they'll send back something like "101." If I were to look at this on the website, it'd just be that number posted on the screen.

The Decorations

But a cake without frosting is hardly a cake at all. So, we'll need to tell them what we'd like as filling, frosting and any decorations on top. I'd love a raspberry filling with white buttercream frosting and then maybe a "Happy Birthday Teddy" in script writing on top.

So again, I could call them and tell them to add that to my order, or we could request it via API. Which gets us to the second API — decoration.

Back to the code!

fakecakebuilder/cake/Decora\on?OrderNo=101&Filling=raspberry&Frosting=buttercream&Text='Happy BirthdayTeddy'&Font=script

So, the Fake Cake Builder now knows to take order 101, add raspberry filling, buttercream frosting, and “Happy Birthday Teddy” in script writing. Cool. We're done! The Fake Cake Builder Shop may respond back with an estimated time. Or, we could get a status update by hitting another API. That could look something like:

fakecakebuilder/cake/Status?OrderNo=101

and they would return a date and time — also cool!

The Enhancements

What happens if we want to make it even easier for our customers? We could take those two APIs and combine them into one because our customer doesn't care that there are two separate processes — baking the cake and decorating it. They just need to order the cake. Who cares what happens in the background? So, we might make a Process API where a customer can order a cake but use the System APIs of both CakeBase and Decoration to actually execute that order.

So, instead of me ordering a cake in two steps, I can do it in one long step like so:

fakecakebuilder/cake/OrderCake?Flavor=Marble&Size=9inround&Layer=3&Filling=raspberry&Frosting=buttercream&Text=”Happy BirthdayTeddy”&Font=script

On the Fake Cake Builder side, they'll separate that request into the two processes, CakeBase and Decoration, and make my cake. Now, the cake company can add a bunch of enhancements if they want. Perhaps Fake Cake Builder wants to allow a customer to change the color of the frosting. They could add a Frosting-Color parameter that would allow a customer to pick their color. They could even make that optional so a customer wouldn't be required to enter it. And because they separated the CakeBase system API from the Decoration system API, the company can update just the Decoration API and still take orders even if that one breaks.

Maybe they want to allow for delayed ordering. They can add that as a parameter too. Maybe they would like to start selling cookie cakes. Well, they'd probably create another Process API that looks something like:

fakecakebuilder/cookie/OrderCookie?ParametersGoHere

What if I as a customer want to also order balloons anytime I order a cake? Perhaps I could string two separate company's APIs together in a single form so that when I submit a cake order it also orders balloons with the exact same text. Neither of those companies would know. But as a customer, I’d be delighted because I can do my decoration ordering in one stop.

Even more on the nose, a customer doesn't actually want to type all that into an address bar in their browser. They want a form to submit on their behalf. But because all Fake Cake Builder needs is that URL string, I can create any customer experience I want. Want an app? As long as the app generates that URL and submits it to Fake Cake Builder you can build an app. Want to build a web form? Build one that hits that URL when the customer hits submit.Want to build an Alexa app? Make Alexa ask each of those parameters in turn and then have Alexa submit it. We've abstracted away the customer experience from the process. This is a HUGE improvement from tying the process directly to the application.

What about Mutual of Omaha?

What's this have to do with us? Well, the same concept applies to Mutual of Omaha. We use system APIs that are roughly correlated to processes to combine into process APIs that are correlated to customer experiences. The customer doesn't care that it may take 147 steps to take an application. They just want to submit an application.

And these process APIs are what we're measuring our success against this year. Our goal is to increase the number we have in production by the end of 2022. These composable APIs are great for adding features without blowing up an entire customer experience. They abstract away the things that don't matter to the customer. And a customer may even want to combine multiple APIs (ours or others) that would create an entirely new experience. We can submit data to that API in a variety of ways, including multiple web forms, apps, Alexa and more. This is the magic of APIs. This is why our ambition is 100% API architecture.