Skip to main content
Bumped by Community user
Bumped by Community user
deleted 4 characters in body
Source Link

During my IT school years, I was told that including rows identifiers from a database in the resource URL, in the context of a REST API, is a bad practice. To my understanding, the rationale behind this statement is that exposing technical database identifiers is a security breach.

For instance, say I have a table USER_ACCOUNTS(id, username) in my database. Say I’m using a REST API to expose the user accounts data. How would I expose the URL without using the real column ID ?

If the user ID is 3 in my database and I want to access his profile, how would I design the URL without having something like /users/3 ?

Is it true that exposing database IDs in the URL is a bad practice ? If so, what are the alternatives ?

I thought of using a hash & salt value instead of the real, plain ID, but I can already see many drawbacks to this solution.

How do you deal with exposing database identifiers in your URLs ? What are the some of the best practices to deal with this issue ?

During my IT school years, I was told that including rows identifiers from a database in the resource URL, in the context of a REST API, is a bad practice. To my understanding, the rationale behind this statement is that exposing technical database identifiers is a security breach.

For instance, say I have a table USER_ACCOUNTS(id, username) in my database. Say I’m using a REST API to expose the user accounts data. How would I expose the URL without using the real column ID ?

If the user ID is 3 in my database and I want to access his profile, how would I design the URL without having something like /users/3 ?

Is it true that exposing database IDs in the URL is a bad practice ? If so, what are the alternatives ?

I thought of using a hash & salt value instead of the real, plain ID, but I can already see many drawbacks to this solution.

How do you deal with exposing database identifiers in your URLs ? What are the some of the best practices to deal with this issue ?

During my IT school years, I was told that including rows identifiers from a database in the resource URL, in the context of a REST API, is a bad practice. To my understanding, the rationale behind this statement is that exposing technical database identifiers is a security breach.

For instance, say I have a table USER_ACCOUNTS(id, username) in my database. Say I’m using a REST API to expose the user accounts data. How would I expose the URL without using the real column ID ?

If the user ID is 3 in my database and I want to access his profile, how would I design the URL without having something like /users/3 ?

Is it true that exposing database IDs in the URL is a bad practice ? If so, what are the alternatives ?

I thought of using a hash & salt value instead of the real, plain ID, but I can already see many drawbacks to this solution.

How do you deal with exposing database identifiers in your URLs ? What are some of the best practices to deal with this issue ?

Source Link

How to not use database identifiers in a URL in the context of a REST API

During my IT school years, I was told that including rows identifiers from a database in the resource URL, in the context of a REST API, is a bad practice. To my understanding, the rationale behind this statement is that exposing technical database identifiers is a security breach.

For instance, say I have a table USER_ACCOUNTS(id, username) in my database. Say I’m using a REST API to expose the user accounts data. How would I expose the URL without using the real column ID ?

If the user ID is 3 in my database and I want to access his profile, how would I design the URL without having something like /users/3 ?

Is it true that exposing database IDs in the URL is a bad practice ? If so, what are the alternatives ?

I thought of using a hash & salt value instead of the real, plain ID, but I can already see many drawbacks to this solution.

How do you deal with exposing database identifiers in your URLs ? What are the some of the best practices to deal with this issue ?