ResourceSupport.getId() too restrictive

[deepakpol]

Having ResourceSupport.getId() method return Link is too restrictive IMO. It makes my representation unable to have id field and corresponding getId() method with different type. It seems a very common use case to assume in UI that the id field of resource would return actual id of the resource and not a link.
Probably ResourceSupport could also be made generic where the id return type is passed by the class extending ResourceSupport.

[odrotbohm]

In REST the id of a resource is its URI (hence Unique Resource Identifier). See a more in depth discussion over in the issue tracker of Spring Data REST. The purpose of these classes is to build representations for a REST service, so we need to stick to the rules here. You can still expose properties used as id's in backend systems if need but I'd strongly recommend against this as you essentially leak internals.

[stephaneeybert]

How to do a PUSH operation without leaking the internal id then ?

[stephaneeybert]

Why naming this resource identifier for what it means and not for what it is ? It is fine that the REST meaning of it is an identifier. But why should we care more for the meaning it carries than for what it is ? Following that logic, we'd have to rename the org.springframework.hateoas.Link class org.springframework.hateoas.Id then. And if the REST identifier is the URI then why seeing as a REST identifier something that contains more than just the URI ? Is the rel property also part of the REST identifier ? Having the getLink getter would be consistent with the naming choice of the existing implementation of the Link class, it would not place any assumption on the meaning of it (as being a REST identifier), and it would not be obtrusive to us clients.

[rvanker]

ResourceSupport :: public Link getId() Why not following bean definition: public Link getLink()
Doing so makes is easy to add ResourceSupport as a superclass to existing domain objects that already have the method public Integer getId(). This is not possible now and unnecessary limits the use of spring-hateoas

[cl4r1ty]

I tried to implement this today and immediately ran into the getId() issue.

You reference spring-data-rest but the issues seem to be wiped from that repo. On top of that looking at the objects used in spring-data-rest you find them using getId(). (https://github.com/spring-projects/spring-data-rest/blob/master/spring-data-rest-example/src/main/java/org/springframework/data/rest/example/jpa/Person.java)

I understand its REST and everything but it seems like a common use case in a lot of spring projects and would entail a huge refactor to already running apps.

What's the solution for this? Or is there one other than using UUID key? (Might have been one on the other repo but its gone now)

[charroux]

On the client side, self rel is not enough to know which kind of object we use. How can I discover this is a person in the following example (I can't deduce it from href since the server implementation can change) ?
{
"name": "Derek",
"links" : [
{ "rel" : "self", "href" : "http://myhost/people/derek" }
]
}
Something like that should be useful:
{
"name": "Derek",
"links" : [
{ "rel" : "self", "href" : "http://myhost/people/derek" }
],
"id":{ "rel" : "person", "href" : "http://myhost/people/derek" }
}

[miguelcobain]

I assume that spring-hateoas tries to force developers to use the best practices as possible. The id "sort of" becomes the self link.
In my case I ended up not leaking the internal id's at all. Much happier. Why would the client need it? I would say that if it needs it, that's because it is building URLs itself. And if it is doing it, you shouldn't even need this project or hateoas at all.

[stephaneeybert]

Hi Miguel,
I agree that leaking the internal is best avoided, but you still build your url to be used in a PUT request with the internal id ?

[miguelcobain]

PUT request URL is handled just like any other request or method.
I'll give an example.

First the client requests the api's root resource. And this is the only URL it knows about.

GET https://apiexample.com/api

{
  "link":[
    {
       "rel":"people",
       "href":"https://apiexample.com/api/people"
    }
  ]
}

Then you follow the people link.

GET https://apiexample.com/api/people

{
  "content":[
    {
      "name":"John Doe",
      "age":21,
      "link":[
        {
          "rel":"self",
          "href":"https://apiexample.com/api/people/1"
        }
      ]
    },
    {
      "name":"Eve",
      "age":21,
      "link":[
        {
          "rel":"self",
          "href":"https://apiexample.com/api/people/2"
        }
      ]
    }
  ],
  "link":[
    {
       "rel":"self",
       "href":"https://apiexample.com/api/people?page=0&pageSize=20"
    },
    {
       "rel":"next",
       "href":"https://apiexample.com/api/people?page=1&pageSize=20"
    }
    //other paging related links
  ]
}

This is a paginated resource.
Now, let's say you want to update (PUT) John Doe to age 22, for example. Just do a PUT to the self link.

PUT https://apiexample.com/api/people/1

{
  "name":"John Doe",
  "age":22
}

Similarly, imagine you want to create a new person. No problem, just POST to the people route.

POST https://apiexample.com/api/people

{
  "name":"John Doe",
  "age":22
}

The only thing hardcoded/known beforehand is this relationship between verbs and rels. I think this may be the next level of HATEOAS, but I think this is already a pretty decent level of independence/hypermedia driven.

In this case, internal id's are indeed in the link. But it's different. The client doesn't explicitly use the id to build an url. You could, for example, replace your id for an uuid, for example. Or even change the url scheme. The client wouldn't complain as long as you keep the rel's steps intact.
I'm assuming that you would only PUT something you already know about, right? So, you need to first retrieve the resource you want to update and only then update. When you retrieve the resource initially, then you know it's url through the self link.

Think of it like surfing a website. You first get the root, then surf through the links, and eventually you can reach a form and POST/PUT and that is also a link.

Sorry if I'm missing something or something wasn't exactly "REST compliant". Please add any corrections, suggestions or comments.

[stephaneeybert]

Hi Miguel,
Thanks for your answer, your example is a good showcase !

[jeffsheets]

I agree that the self link is the correct way to GET/PUT/POST for the object.

But there are also many legacy applications where the id field is a displayable value to the user in some form: perhaps the id is also the username, or perhaps the id is a recognizable industry value that the users like to view on the screen.

In those cases we are having to work around to display the id value on the screen since it is not easily retrievable from the json object. This is more an issue in legacy systems where we do not have the permission to modify the legacy database tables to have a system identifier.

For this reason I would like to have the id available in json along with the self link. Or at a minimum have the option to configure this behavior.

[stephaneeybert]

I'm now wrking on an AngularJS project and I create an abstract resource class holding a @JsonProperty("id") private Long id; and extend from it for all project resources.

It's easier to pass the id from a list view to an edit view. Just use the resource id in the view: ui-sref="/admins/edit({adminId: admin.id})"

I reckon some would manage to identify a resource by its REST URL in their client application and be able to pass this data around views.

If someone has some directions on doing this in AngularJS I'd be happy to give it a try.

Sorry if I'm bit off the mark with this comment.

[ceefour]

👍 for this. Please rename ResourceSupport.getId() to (my proposal) getSelfLink()

Surely I can create @JsonProperty("id") getItemId() or something else, but Spring HATEOAS would do well to be a bit less opinionated. Please be Spring, Spring is flexible.

[gregturn]

To work with hypermedia and links, I've discovered that it's most practical to do things like embed URIs provided by the hypermedia as data attributes in HTML elements. If you look at https://github.com/gregturn/spring-a-gram/blob/master/src/main/resources/static/app/main.js#L24, you can see where I create data-uri and store the whole URI. This way, in the future when I need to PATCH or PUT, I use the whole link. This decouples my front end from having to understand id's.

Regarding Angular, I saw someone else write an Angular + Spring demo app, but they used a lot of outdated patterns. I essentially rewrote the whole thing, throwing out hand written JDBC and controllers, and instead used Spring Data REST. It was super easy to tweak the Angular bits to work with this. See https://github.com/gregturn/task-manager-app.