When the Eiffel tower was built in 1887, many Parisians thought it was really ugly. 150 years on, it has become an undeniable icon of France. When the PT Cruiser was unleashed upon the world in 2000, many people thought it was really ugly. 25 years later, many people still think it’s really ugly. 

They say something can “age like milk” or “like wine,” but sometimes milk ages into a fine parmesan cheese——and wine ages into a box of Franzia. Could the PT Cruiser have its parmesan moment? Maybe. Maybe (probably) not. The point is that beauty is not only subjective——it’s also subject to change over time.

We can spend all day debating form vs. function over physical stuff like cars, buildings, and furniture. But what about APIs——where the function arguably is the form? That would imply APIs have no expressiveness, no inherent aesthetic, and therefore nothing to evaluate stylistically. Just inputs, outputs, and logic——nothing to touch, smell, taste, or hear. 

Is that really the case? 

To answer this, we’ll take a look at some design history, listen to some music, and talk to someone who’s spent decades building APIs. Along the way, we’re probably going to test some logical boundaries, but for a good cause: To understand whether an API can be meaningfully evaluated for its design——the same way a physical object could be. 

In the physical world, design moves in eras——classical, modern, brutalist, postmodern, and beyond. Can APIs be looked at through that same lens? Well, who’s gonna stop us?

SOAP: The Baroque API  

Go ahead and play the music. It’s Vivaldi’s Violin Concerto in E minor, RV278. The music sets the tone of the Baroque era well. It’s super detailed, complex, explosive in ways that impress the listener. It is no less ornate than Exhibit C, the roof of the Chiesa Maria de Santa Pieta, where Vivaldi composed many of his famous works. Vibrant colors. Gold everywhere. You get the idea. 

Now, let’s look at Exhibit D: a SOAP request. All it’s doing is asking for a user. But it does so by wrapping that request in an envelope, nesting it inside a body, and declaring a namespace——just to be heard.

This isn’t a query. It’s a procession. Protocol for protocol’s sake. Like the gold-plated ceiling of an Italian cathedral, it’s built to impress——not to be used. You get symmetry, hierarchy, layers of decoration. Nothing is out of place, but everything is in the way.

Keith Casey, an API developer since the early 2000s——starting at the Library of Congress, later at Twilio, Okta, and beyond——had this to say about SOAP: “SOAP is like getting a mortgage. You have to provide all this documentation up front.” 

SOAP wasn’t complex for no reason. It came out of an era where systems didn’t trust each other——or even agree on basic protocols or data structures——and every interaction had to be defined, validated, and secured. The structure wasn’t ornamental; it was defensive. Similarly, in the Baroque era, ornament wasn’t for the sake of ornament. It was an expression of power, and therefore control, often by monarchs. 

What we’ll call control-freakism is a hallmark of both Baroque and SOAP: two eras that used complexity as a way to maintain order. 

REST, Bauhaus, & Modernism

Bauhaus wasn’t an evolution of Baroque——it was a rebellion. No more ornaments. No more processions. No more pageantry. It was, in many ways, a rejection of frivolity——coinciding with the demise of monarchy and the turbulent rise of liberal democracy in Europe. 

If you want to change up the Vivaldi, have a listen to this, Steve Reich’s “Music for 18 musicians.” You can pick out each element in the music individually. It’s bare——but not hollow.

Now, let’s look at Exhibit F——a REST request. It’s direct. No envelopes. No nested declarations. You just ask for a user——GET /users/12345——and you get a user. Is it a response to the over-engineering of SOAP? Is it deliberate rebellion akin to Bauhaus vs Baroque?

Keith Casey put it this way: “REST ... stripped away all the kind of bullshit of SOAP ... It doesn’t require special tooling to understand.” That’s the whole point. You could open a browser, paste a URL, and something meaningful would happen. 

REST “came in at these very low-risk, low-stakes opportunities... people were able to play with it, iterate on it, and ... figure out the sharp edges when the stakes were so low it wasn’t a problem.”

Unlike SOAP, which required full commitment before you even knew if it would work, REST lets developers move fast and think creatively. You can just start.

“Suddenly,” Keith said, “I didn’t have to have the same stack you had. I could have real interoperability.” REST wasn’t trying to be elegant, it just happened to be. 

“Think of you’re walking down the sidewalk,” he told me. “Because the sidewalk is smooth and straight——you don’t have to think about the sidewalk. But the second you come into a gap on the sidewalk or one stone is higher ... suddenly that inconsistency can make you trip and fall, it can distract you.” This is Keith’s perspective not necessarily on REST, but on the difference between a good and bad API in general. 

Raw JSON & Brutalism

Brutalism isn’t typically associated with music, although Dmitri Shostakovich would like to have a word. Hit play on his Prelude and Fugue No. 14 in E-flat minor——a jarring, almost monotone composition stripped down to bare elements. The brutality lies not just in the music itself, but in the experience of a man who composed through the ravages of war and totalitarianism. 

It’s not unlike Exhibit G, the Chuvash State Opera and Ballet Theater in Cheboksary, Russia——a mortifying, raw, exposed concrete icon of brutalist architecture. JSON has the same posture. It's anything but flexible——but it works. It doesn’t guide you. It doesn’t apologize. You get raw data——bracketed, comma-bound, and structurally indifferent to your feelings. Miss a bracket, and the whole thing collapses. If REST was a smooth sidewalk, JSON is a flight of concrete stairs.

Shostakovich once carried 200 state-approved answers in his suitcase on a trip to New York. Say the wrong thing? Go to Soviet jail. JSON also demands obedience——because leaving anything up to interpretation will be your downfall.

GraphQL & postmodernism

Welcome to postmodernism——where traditional procedures and hierarchies are out the window. If a banana duct-taped to a wall can be art (see Exhibit K), why can’t an Android touch screen be used to open and close the windows in your car (see Exhibit I)? It’s change for the sake of change——not necessarily progress. Can’t hear the music? It’s John Cage’s 4’33 (there isn’t any music). 

Now, moving onto Exhibit J——a GraphQL request. At first glance, it looks clean. But that elegance is deceptive, because it’s not a system with rules——it’s a system with options.

GraphQL doesn’t tell you what to ask for. You tell it. That’s the whole point. You define the structure of the response yourself. This is the sort of openness to interpretation that would make the brutalists in the room very upset. 

Now, is GraphQL the banana-duct-taped-to-a-wall of API design? A gesture that says: “you decide what this is”?

Here’s Keith Casey’s take: “I’m hesitant to say [GraphQL is] a piece of shit——I won’t go quite that far——but I would say it encourages people to be sloppy.” Why?

“It’s the idea of, well, I can just build my query in the request, send it off, and then you as the API developer, builder, whatever, can pull all the data together and give it to me.” In other words, it’s not a protocol——it’s a negotiation. 

If SOAP and the baroque used complexity as a form of control, then GraphQL and the postmodernists offer complexity as a form of freedom. The problem is: free will can get freaky——and sometimes even downright dangerous. 

- - - - - -

So, now that you’ve made it all the way here—can we finally say whether an API can be beautiful?

Arguably, yes. In fact, any API can be. But that beauty lies within how the API is experienced and felt——not necessarily in how it’s built. 

Let’s put it this way: an architect may build a seemingly hideous, brutalist apartment block. The architect moves on, but the people who live there stay. And the trials and joys of the lives lived within can bring contextual beauty to the otherwise gloomy building. 

APIs are similar. Those who’ve built them may have moved on. But the developers that call on them are here to stay. Yet, if what the builders left behind still works on its own——and supports life being built on top of it——then maybe that’s beauty too.