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.

AI Didn’t Know the Law. It Made the Path Visible.

How I finally appealed a denied insurance claim

Kate (now 21!) had dental surgery on 12/01/2025, a 4-5 hour procedure.

I don’t pay much attention to insurance stuff because it’s overwhelming. Before I joined my current company, it was also genuinely hard and expensive. Every day I’m grateful for my employer's coverage and, by extension, the generosity that makes it possible.

Kate has had 3–4 major dental surgeries over the last couple of years. She doesn’t technically qualify as “hillbilly” yet. Her dentist says that’s eight or fewer teeth. 😆

Kate also requires general anesthesia. 

Dental surgery is not cheap, which means I know the exact limits of our dental coverage: $2,500 per year. Her most recent surgery came in just north of five figures. Thankfully, Kate has Medicaid as secondary insurance. Less thankfully, her dentist, who is excellent, no longer accepts Medicaid. 

About a month later, another bill arrived. This one was for anesthesia. It was roughly half the cost of the surgery itself. Sigh. 

I called the anesthesiologist’s office and learned they didn’t have Kate’s current insurance information. I gave it to them and asked them to resubmit the claim. They did. Denied. Denial code: 001. 

This is classified as dental work, so medical does not cover anesthesia. I think. 001 isn’t super descriptive, it says:

We denied this service. Your benefits don't cover this kind of care. You can check your plan documents or go to the Benefits section of our website for a searchable list of what's covered.

Not super descriptive. AI (Gemini CLI) to the rescue. I downloaded the EOB and asked Gemini to scan it. It did and came back the above so I asked if it there were any other reasons possible?

While the document itself doesn't provide a specific medical rationale beyond the generic reason code 001 ("Your benefits don't cover this kind of care"), we can infer a highly likely explanation based on Kate's profile and typical insurance practices. Given that Kate's diagnosis is Developmentally Disabled, the most common scenario for an automatic denial like this is:

The Underlying Procedure was Dental: It is very common for special needs individuals to require general anesthesia for routine dental work that a neurotypical patient might do awake. Because routine dental care is generally excluded from medical plans, the automated claims system will automatically deny the associated anesthesia as "not covered care," even though the anesthesia itself is medically necessary due to her disability.

“Kate’s profile.” That’s a reference to other AI work I’ve been doing trying to make my life just a bit easier handling all the bureaucracy surrounding her (Guardianship, SSI, etc). My next prompt was, “How do I appeal?”

This is where it gets super fun and unexpected. With that other context, “Kate’s Profile,” Gemini’s first response was:

I will research Florida's specific legal requirements for anesthesia coverage for individuals with developmental disabilities and provide the exact steps to file the appeal with the insurance provider.

It came back with this:

✦ To appeal this denial, you need to challenge the automated determination that the care is "not covered." Because Kate has a developmental disability, Florida law likely requires them to cover the anesthesia and facility charges, even if the underlying procedure (like dental work) is not normally covered. 

The Strategy: Use Florida Law
Florida law mandates that health insurance policies must cover general anesthesia and associated hospital/facility charges for dental procedures if the patient meets specific criteria. Since Kate is over age 8, your appeal will rely on:

Statute: Fla. Stat. § 627.65755

The Argument: Kate has a developmental disability (as noted in her profile.json) that creates a "significant or undue medical risk" if dental or minor medical treatment were performed without general anesthesia in a controlled environment.

This isn’t an example of AI “knowing the law.” It’s an example of AI making a path visible that was previously opaque enough to stop me from trying. 

This is the second time in as many weeks that it has helped me overcome a bureaucratic hurdle that usually stops me from pursuing a thing. The last time, it helped me transfer Kate’s Conservator Payee (SSI) from my mom to myself. My mom handled it previously because I would not engage with that labyrinthine system. She’s retired. It took her 10 months. I’m ridiculously grateful and lucky. 

If you’re looking for ways to utilize AI, here’s another. 

*Editor's Note

I posted this internally a few weeks back. I'm slowing making my way back out into public waters. 

It's Been a Minute...

 

Hi.

It's been a while. 

Not sure if this is a one-off or not, but I'm going to give it another go. I miss writing (publicly).

Like, this is super awkward. "What do I say?"

"How are you?"

"Things are good."

"How are you?"

Real World SQL and PL/SQL: Advice from the Experts

Because my hero is Cary Millsap, I'm going to do what he did and publish my foreword Preface. All joking aside, I consider myself incredibly fortunate to have been included in this project. I learned...a lot, by simply trying to find the author's mistakes (and there were not many). There was a lot more work than I expected, as well. (Technical) Editing is lot easier than writing, to be sure.

Brendan Tierney and Heli Helskyaho approached me in March 2015 about being an author on this book, along with Arup Nanda and Alex Nuijten. Soon after, we picked up Martin Widlake. To say that I was honored to be asked would be a gross understatement. Rather quickly though, I realized that I did not have the mental energy to devote to the project and didn’t want to put the other authors at risk. Still wanting to be part of the book, I suggested that I be the Technical Editor and they graciously accepted my new role.

This is my first official role as Technical Editor, but I’ve been doing it for years through work; checking my work, checking others work, etc. Having a touch of Obsessive Compulsive Disorder (OCD) helps greatly.

All testing was done with the pre-built Database App Development VM provided by OTN/Oracle which made things easy. Configuration for testing was simple with the instructions provided in those chapters that required it.

One of my biggest challenges was the multi-tenant architecture of Oracle 12c. I haven’t done DBA type work in a few years, so trying to figure out if I should be doing something in the root container (CDB) or the pluggable database (PDB) was fun. Other than that though, the instructions provided by the authors were pretty easy to follow.

Design (data modeling, Edition Based Redefinition, VPD), Security (Redaction/Masking, Encryption/Hashing), Coding (Reg Ex, PL/SQL, SQL), Instrumentation, and “Reporting” or turning that raw data into actionable information (Data Mining, Oracle R, Predictive Queries). These topics are covered in detail throughout this book. Everything a developer would need to build an application from scratch.

Probably my favorite part of this endeavor is that I was forced to do more than simply see if it works. Typically when reading a book, or blog entry, I’ll grab the technical solution and move on often skipping the Why, When, and Where. How, to me, is relatively easy. I read AskTom daily for many years, it was my way of taking a break without getting in trouble. At first, it was to see how particular solutions were solved, occasionally using it for my own problems. After a year or two, I wanted to understand the Why of doing it a certain way and would look for those responses where Tom provided insight into his approach.

That’s what I got reviewing this book. I was allowed into their minds, to not only see How they solved technical problems, but Why. This is invaluable for developer’s and DBAs. Most of us can figure out How to solve specific technical issues, but to reach that next level we need to understand the Why, When and Where. This book provides that.