Irritating behavior in rest/search/searchMethod about spring-data-rest HOT 6 CLOSED

Due the problems of Jackson Mapping Links like described above I wrote a snippet that loads the links. It looks like this:

ResponseEntity<Object> objRef = restTemplate.getForEntity(url, Object.class);

        if (objRef != null && objRef.getStatusCode().compareTo(HttpStatus.OK) == 0) {
            ArrayList<HashMap<String, String>> linkMaps = (ArrayList<HashMap<String, String>>) objRef.getBody();
            for (HashMap<String, String> linkMap : linkMaps) {
                for (Map.Entry<String, String> link : linkMap.entrySet()) {
                    if (link.getKey().equals("href")) {
                        response = restTemplate.getForEntity(link.getValue(), clazz);
                    }
                }               
                object = (T) response.getBody();
            }
        }

And in my opinion it is awful. Adding the _links back to the result would make it much more comfortable and straight-forward, clean and consistent. Not only for a Java client side as well as for others like Javascript access.

from spring-data-rest.

Sorry I didn't notice this when you posted it. I wasn't getting GitHub notifications of issues for some weird reason.

That code isn't pretty, you're right! :/

I'll put the _links structure back into the search results and build a snapshot with that. If that's easier to work with, then we'll go with that for the next release (wish I'd seen this sooner..I could have gotten it in before I released RC1 :( ).

from spring-data-rest.

Thanks, I will wait for the build and try it again afterwards.

from spring-data-rest.

This isn't as easy as simply adding a _links structure to the response. The problem is that results returned might have to be entities rendered as JSON documents because there is no corresponding Repository exported for them.

This means search results would have to be nested something like this:

{
    "results": [
        ... entities that don't have Repositories exported ...
    ],
    "_links": [
        ... links ...
    ]
}

This isn't a problem per se, it's just a departure from the current representation and is a breaking change.

from spring-data-rest.

Jon, yep that's right. For this case I was thinking about the following solution. If I do have a specific search, I am aware of the possible results on the client side. In this case, I could easily create a POJO, inheriting from LinkType (_links(rel,ref)) to get the result.

The question here is, relying on the discussion via e-mail yesterday, if this is necessary at all, because if we stick to your or Olivers suggestion, we would have to types of search results. The first would be a pure list of links to core result objects, while the second would be the core results directly, without the link section before.

from spring-data-rest.

Actually the structure of an object with two properties ("results" and "_links") is necessary in all cases because even when sending back a list of entity results, there are links associated with paging and searches. I still have to have a "_links" section to the response, it's just that it won't have any more links in it than prev/next, search, etc...

The media type is basically a switch to tell the system whether to fill in "result" or "_links". The basic structure of the response at the root level will be the same in any case.

from spring-data-rest.