ORACLENERD

If you were a database guy in the early 2000s, APIs didn’t exactly show up with a gift basket and a smile.

They showed up as these massive, scary-looking blocks of XML that people called SOAP. Or maybe it was a WSDL? Honestly, I could barely spell those acronyms, let alone tell you what they were supposed to do. I didn’t have a Computer Science degree, and looking at those files felt like I’d wandered into a high-level physics lecture by mistake.

I was brand new to IT, and the whole "web service" thing was just...intimidating. It felt like a club I didn't have the password for. I didn't know how they worked, I didn't know why people liked them, and I certainly didn't want to admit I was lost. So I did what anyone does when they’re staring at something that makes them feel out of their depth: I retreated to safety.

I stayed where things made sense. Tables. Sets. SQL and PL/SQL. Logic sitting right next to the data where it belongs. I could look at a table and understand it. I could write a query and get a result. The database was my safe harbor in a storm of jargon I didn't understand.

That bias stuck with me for a long time. 

REST Didn’t Fix the Mindset 

Fast forward a decade. SOAP was finally out of fashion (h/t to everyone who survived that era). REST and JSON were the new hotness. We were told this was "better." And structurally, sure, it was. 

A few years back, I poked around with a Strava app to see if I was just being a crank. Clean endpoints. JSON payloads. Reasonable docs. 

And it was still exhausting. 

Not because REST was inherently bad, but because the underlying mindset hadn't shifted an inch. I was still being handed "object-shaped" payloads and expected to navigate an object graph like a tourist without a map. Nested structures. Lists of things containing lists of other things. Manual parsing until my eyes bled. 

That wasn’t a data problem. It was an OO worldview leaking all over my integration boundary. I wasn’t getting result sets; I was getting objects pretending to be data. 

PL/SQL Was Already the API (We Just Forgot) 

Here’s the part that often gets missed: PL/SQL has always been the API. 

A PL/SQL procedure returning a ref cursor isn't some low-level implementation detail. It’s a contract. It’s the database saying, “Here is a defined shape of data. Consume it as a set.” 

That distinction matters. 

A result set is declarative. It’s complete. It has no behavior, no lifecycle, no implied navigation path. It just is. Objects, on the other hand, carry all this baggage about how they want to be used. They imply traversal, ownership, and state transitions. 

One is about truth. The other is about interaction. Most APIs were designed by app devs, so they expose objects. Not data. 

It's probably why I loved APEX so much. It didn't ask me to pretend my data was a "user object," it just asked me for the query.

AI Is the New Translation Layer 

What finally broke the barrier for me wasn't some breakthrough in REST design. It was AI.

Today, I don't waste my life manually mapping JSON payloads into structures. I don’t read API docs line-by-line trying to guess where the edge cases are hiding. I just hand the spec to the machine.

My workflow is now dead simple:

1. Grab the API key. 
2. Stash it in the system keychain. 
3. Give the spec to the AI and let it do the grunt work. 

Pagination, retries, flattening, normalization; the machine handles all the deterministic boring stuff. What I want on the other side isn't an object model.

I want result sets.

Give me the rows and columns. Give me something I can join, constrain, and reason about at rest. 

From OO Friction to Set-Based Speed 

Once that API output is normalized into a set, the friction evaporates. 

I stop worrying about endpoint "shapes" and start thinking about data quality. I stop writing glue code and start defining truth. This is where PL/SQL shines. It doesn't want you to think in objects; it wants you to think in operations over sets. It wants logic close enough to the data that violating a business rule is actually difficult.

APIs that dump object graphs on you fight that model. APIs that deliver result sets fit into it like a glove. 

APIs Are Just Addresses 

If you look at it the right way, APIs aren't applications. They're just addresses.

A table is one physical address. A view is another. A remote API endpoint is just a slightly more annoying address. The "brain"—the business definition—doesn't live at the address. Neither does the "brawn" (the execution).

Those belong in a stable, declarative core. For me, that’s still the database.

With AI translating API specs into tabular, set-friendly forms, external APIs finally behave like first-class data sources instead of OO intrusions. 

The New Era of Data Integration

For a long time, integrating with external APIs felt like a chore because it forced us to abandon our set-based mindset. We were stuck parsing hierarchies instead of querying data. 

That manual struggle is over. 

With AI acting as the translation layer, we can finally overcome that old "impedance mismatch" between objects and sets. We can normalize the world's objects into the sets we need to build real applications. The "API barrier" has turned into a bridge. We can stop worrying about the shape of the payload and get back to what we do best: defining the truth of the data.