Denkanstoß - Hash ID für URL

[beta20]

Hallo zusammen,

ich benötige einen Denkanstoß.
Ich würde gerne meine URL´s so aufbauen, dass man nicht gleich sehen kann wieviele Einträge in meiner Datenbank sind.
Also Bsp. habe ich eine Entity "Article". Meine URL (mit Parameter) sieht dann derzeit so aus:
www.mydomain.com/article?id=1
-> Die "1" am Ende ist der Parameter meiner ID

Meine Idee ist, dass ich diese ID mit einem Hash versehe, sodass nicht gleich für den User ersichtlich ist, dass ich nur 1 Eintrag habe....
Also z.B.
www.mydomain.com/article?id=1asasasd5485asdas33asasads

In der DB habeich mit Hibernate / JPA bereits eine zusätzliches Feld hinzugefügt.
String hashKey

Dieses Feld habe ich in @Presist (also bevor das Objekt erstellt wird) hinzugenommen, und dann anhand der echten "ID", welche automatisch vom DB-System hochgezählt wird mittels MD5 einen Key generiert.
Das Problem ist nun allerdings, dass beim Ausführen der Funktion (den MD5 Hash) generieren die ID noch gar nicht exisiert und demnach mein String hashKey immer defaultmäßig den Hash von "0" zeigt.

Gibt es hier andere Möglichkeiten?
Danke für jede Hilfe

 

[thecain]

uuid von der DB generieren lassen oder von Hibernate

z.b.

@Id
@GeneratedValue(generator = "uuid")
@GenericGenerator(name = "uuid", strategy = "uuid2")
@Column(name = "ID")
private String id;

 

[beta20]

Danke - ich habe allerdings schon eine @ID
- Kann ich zwei davon haben?
- UUID ist auch wirklich unique?
- Wird hier automatisch ein Hash erstellt durch Hibernate oder muss ich "id" extra nochmal hashen?

 

[mrBrown]

ich habe allerdings schon eine @ID
- Kann ich zwei davon haben?

Nein, du ersetzt die bisherige damit.

- UUID ist auch wirklich unique?

praktisch ja (theoretisch könnten doppelte Auftreten, die Wahrscheinlichkeit ist aber zu gering um relevant zu sein)

- Wird hier automatisch ein Hash erstellt durch Hibernate oder muss ich "id" extra nochmal hashen?

Eine UUID ist zB "550e8400-e29b-11d4-a716-446655440000", was soll man da noch hashen?

 

[Thallius]

Wie wäre es die ID einfach mittels POST mitzugeben?

Klar kann man das mit den Developer-Tools dann immer noch ansehen aber immerhin nicht mehr so ersichtlich für jeden. Und einfach ist es auch. Ich würde eh nie mit GET arbeiten wenn es nicht absolute unverzichtbar ist. Das läd die Leute ja geradezu dazu ein auch mal ein paar andere PArameter auszuprobieren.

 

[mrBrown]

Wie wäre es die ID einfach mittels POST mitzugeben?

Weil POST eine ganz andere Bedeutung und Funktionsweise hat als GET?
Die sind nicht miteinander ersetzbar.

Ich würde eh nie mit GET arbeiten wenn es nicht absolute unverzichtbar ist. Das läd die Leute ja geradezu dazu ein auch mal ein paar andere PArameter auszuprobieren.

Dann hast du wohl noch nie einen REST-Service benutzt geschweige denn programmiert.
Die Validierung der Parameter *muss* in jedem Fall gemacht werden. Wenn "Parameter ausprobieren" für die Anwendung ein Problem ist, ist der Entwickler das Problem.

 

[Thallius]

Wo ist definiert, dass bei REST die Parameter über die URL gemacht werden müssen?

 

[mrBrown]

Wo ist definiert, dass bei REST die Parameter über GET gemacht werden?

Nirgends, ist in der Formulierung auch Unsinn. Wie schaffst du es, auf genau das einzugehen, was überhaupt nicht angesprochen wurde? Wäre irgendwie sinnvoller, auf die Punkte einzugehen, die ich auch genannt habe...
(Wobei du da einen schönen Punkt ansprichst, uU ist das hier als Parameter falsch und wäre als Path-Variable besser aber darum gehts ja nicht)


Man sollte die für die entsprechende Funktion geeignete Methode nutzen.
Und für das Erhalten einer Resource (um das es hier geht, erhalten des Artikels mit Artikelnummer N), ist GET das passende.
Wenn du was zum Lesen willst: RFC 7231.


Wie sähe eigentlich ein Link zu dem Artikel aus, wenn das ein POST-Request ist, kannst du den hier auch so anklickbar einfügen, wie die obigen?