UUID Killed REST

🤖 "From a practical standpoint..." — A small question that turned into a whole thing

I was implementing a coding test assignment using an in-memory approach.
The goal was to satisfy the requirements first and then ask myself,
“If I were building this for real, how would I design it?”

There was no FastAPI, no SQLAlchemy, no database.
Just pure Python logic.
And naturally, I was assigning primary keys like this: customer_id_seq += 1,
mimicking auto-increment behavior.

Then GPT dropped this on me:

🤖 From a practical standpoint:
  • Real-world services often use UUIDs
  • Or ULID/Snowflake IDs for time-sortable uniqueness
  • Using incrementing integers like this is a typical in-memory simulation pattern

The part about "mimicking" didn’t bother me. It was true.
If I were building this in production, I’d use MySQL and AUTO_INCREMENT.
So yes — it’s mimicry. No argument there.

But what stuck with me was the next part:

“In real services, UUIDs are commonly used…”

Are they really?
Why? For security? For structure?
And more importantly…
Is putting a UUID directly in a URI ever really a beautiful design?

That question was the beginning.
From that moment, I began facing the concept of UUID head-on.

Is UUID security?

Let’s start there.
A lot of people say they use UUIDs for “security.”
Instead of predictable paths like /users/42, they go with something like:

/users/8c12e401-ef14-4ea4-86cd-349fc00c672b/profile
— because it’s “hard to guess.”

But here’s what I believe:

Security in your URIs should come from authorization, not obfuscation.

What if someone brute-forces a real UUID?
And what if that request goes through without authentication?

Then the problem isn’t the UUID.
It’s your security model.

A UUID isn’t protection.
It’s just a name tag that’s harder to guess.

UUIDs are not beautiful in URIs

Whenever I see a UUID in a URI, this is what goes through my mind:

“Ah shit… here we go again…”

RESTful URIs are meant to be readable by humans.
Something like /users/42/profile has structure, clarity, and meaning.
(My blog isn’t even RESTful yet — it's still https://cliche.life/profile/cliche —
but the point is: the structure is human-readable.)

Now compare that to this:

/users/8c12e401-ef14-4ea4-86cd-349fc00c672b/profile
It looks like a pile of machine vomit.

No readability.
No sorting.
No predictability.
Just chaos.

You’ve seen those links, right?
The ones your friend DMs you that are so long, you need to hit “See More” to even unfold the full URL.

Let me give you an example:

Strictly speaking, this isn’t a UUID.
It’s a mess of UTM params, tracking tags, and product data.
But from the perspective of “human-unreadable design,”
it’s exactly the same.

Once again — my apologies to Yodobashi.

REST’s original philosophy was about expressing resource structure through URIs.
UUIDs cut right through that.

REST is dead.
What remains is just a random-token-flavored RPC.

So... are UUIDs garbage?

No. Absolutely not.

UUIDs are useful.
Especially in distributed systems, offline ID generation, or client-side uniqueness.
I respect all that.

But what I am saying is this:

Don’t use UUIDs for security.
Don’t make UUIDs the face of your architecture.
And most of all —
UUIDs are not RESTful.

URIs should be readable by humans.
That’s what REST was about — and what brought me to this work in the first place.

If I can't understand a structure, it has no value to me

This isn’t just a UUID rant.
It’s a statement about how I approach technology.

I hate unnecessary complexity.
If I built the system, I need to be able to understand the structure.

That’s the foundation of design.
And the beginning of ownership.

These days, people build apps with no-code tools,
deploy with a single click,
and talk about monetizing before they even write a function.

But I always come back to this:

“If I can’t understand the system, it’s not mine.”

It’s a rental structure.
And I’m just a user who can’t change a single line of it.

Conclusion

UUIDs are not security.
URIs should be readable.

I still use profile/{username} —
because that structure is mine.
It makes sense to me.
It’s human. It’s elegant.

RESTful? Sure, I like it.
But it’s a means, not a religion.

In the end, design is only beautiful when it works.

So I cleaned up my RESTful endpoints and HTTP methods,
only to realize that HTML forms don’t even support DELETE or PATCH.

If RESTful is the ideal,
then Swagger is my day-to-day reality —
one test at a time, one click at a time.

Yes, I wish my URIs could be beautiful.
But what matters most is this:

I need to understand the URI I create.

That’s my philosophy.
And it’s still breathing today — in profile/{username}.