Allow overriding which field gets exposed in the URI

From what I understand, it is the @Id field in the entity that always gets exposed as the URI.

This is very inconvenient. Usually every object has a low-level DB Id (i.e. the PK) and a business-friendly id (e.g. customerId)

It's a much nicer URL to do

GET /customer/CUST1234 (a customer ID of 'CUST1234')

vs

GET /customer/23434224 (the DB PK of 2343224)

Using the low-level @Id as the URI has 2 major showstopper issues:

a) it is hard to move config data from one environment to another (the PKs in a test env will be totally different from a production one for the same logical entity).

b) it is impossible to write consistent unit tests for the returned JSON, since the "links" section will vary on every run (hence you cannot compare an entire expected JSON vs actual JSON)

It would be great to add a new annotation like @RestId so you could explicitly define which of the entity fields get used in the URI, e.g.

@Entity
public class Customer {

@Id @GeneratedValue(strategy = GenerationType.AUTO)
private Long id;

@RestId
private String customerId;

....
}

No files, tests, or entry points are named. Start by tracing how entity @Id fields become resource URIs and determine how a business-friendly field could be selected instead. Done means the requested override can expose customerId rather than the generated database id, with the behavior covered by tests.