Why does Spring Data REST include “duplicate” links?

5
votes

Hi I am using spring data rest and Ihave a weird issue when I am using PagingAndSortingRepository the response I get has a _self link as expected but with it also gives a duplicate link of the same entity hf:foo as evindent in the below response.

dupicate links "self" : { "href" : "http://localhost:8080/foos/8445" } and "hf:foo" : { "href" : "http://localhost:8080/foos/8445"

  curl http://localhost:8080/foos?page=0&size=1

        {
      "_links" : {
    "first" : {
      "href" : "http://localhost:8080/foos?page=0&size=1"
    },
    "prev" : {
      "href" : "http://localhost:8080/foos?page=0&size=1"
    },
    "self" : {
      "href" : "http://localhost:8080/foos"
    },
    "next" : {
      "href" : "http://localhost:8080/foos?page=2&size=1"
    },
    "last" : {
      "href" : "http://localhost:8080/foos?page=81&size=1"
    }
  },
  "_embedded" : {
    "hf:foos" : [ {
      "name" : "comsi",
      "_links" : {
        "self" : {
          "href" : "http://localhost:8080/foos/8445"
        },
        "hf:foo" : {
          "href" : "http://localhost:8080/foos/8445"
        } ]
      }
    } ]
  },
  "page" : {
    "size" : 1,
    "totalElements" : 82,
    "totalPages" : 82,
    "number" : 1
  }
}

please help .Is it an issue with the curie namespace .

3
javaspringrestspring-mvcspring-data-rest
Can anyone help please! - Gaurav Rawat
It might be me, but I don't see a duplicate link here? self and hf:foo are not the same, by definition. Just as first and prev are not. So what exactly is the issue? - Oliver Drotbohm
Hi @olivergierke I meant the self link is the link of the entity foo hence why we are getting another link for hf:foo which is not an association but point ( localhost:8080/foos/8445) the same entity . this does not happen in 2.4.0.M1 though as put in the ans - Gaurav Rawat

3 Answers

9
votes

What you're seeing here is not a duplicate link as you're claiming. One is the self link that needs to be canonical by definition (i.e. no template parameters).

The other, additional link exposes the resource type (in this case the item resource of a foo. This allows clients to reason about what they expect (what representation, which HTTP verbs to use) when following the link.

Also, that particular link will expose template variables that might apply to that resource. E.g. if a projection is available for Foo instances, the links for the embedded document will look something like this.

 { 
   _links : {
      self : { href : "…/foos/8445"},
      ht:foo : { href : "…/foos/8445{?projection}" }
   }
 }

Now you could argue that the additional link doesn't need to be there if it's just the same as the self link. That would the require the client to be more complex as it basically needs to guard access with a "if there, then use, if not, do something different". That's why we decided to always render it, just to make sure clients that look for resource type based links find them no matter what.

1
votes

If you want to remove that "duplicated" link you can add this Bean:

@Bean
public ResourceProcessor<Resource<?>> entityProcessor() {
  return new ResourceProcessor<Resource<?>>() {
    @Override
    public Resource<?> process(Resource<?> resource) {
      resource.removeLinks();
      return resource;
    }
  };
}
1
votes

use .removeLinks() in the begging of your code to flush all the previous links