a.verrecchia's avatar

Best practice for handling public and internal IDs in REST APIs using UUID and slug columns in Laravel

I have a table that contains a classic auto-incrementing ID and the name of the business. To avoid exposing the business ID to the client, I want to use a UUID. So far, so good. The only thing is that for calling it from the URL, it may be better to have a more user-friendly format like "api/businesses/my-business" instead of "api/businesses/10b940f2-5f8c-42ac-9c35-b6d0de45995b". Therefore, if I add a "slug" column to the table to use for GET requests, while using the UUID for data updates, would this be considered a best practice?

In my case, I need to create a record in a quotes table, and therefore the PATCH will be:

PATCH /api/quotes/4dc93692-0ad9-4131-94fe-b4afec88d037

{ "business_uuid": "10b940f2-5f8c-42ac-9c35-b6d0de45995b", "object": "My quote object", "another_column": "Hello", }

0 likes
4 replies
Sinnbeck's avatar
Sinnbeck
Best Answer
Level 102

Why do you need a "pretty" url at all if it's for an api? I consume many apis and never needed to use user friendly url. I write code that interact with it

a.verrecchia's avatar

@Sinnbeck "I hadn't thought of that, you're right. So I'll work with UUIDs instead of slugs. Let's say that the latter are used for a desktop version with SEO positioning, even though the desktop app consumes the same APIs, the issue doesn't change.

Sinnbeck's avatar

@a.verrecchia but you aren't indexing api routes. For the frontend page a slug might make sense but I would make a separate route for that then. If I work with an api my endpoint shouldn't suddenly change because i updated the name of a post

Also when it comes to seo you probably don't want to use your api anyways. You would use some sort of server side rendering

1 like

Please or to participate in this conversation.