{"action":"created","issue":{"url":"https://api.github.com/repos/spring-projects/spring-hateoas/issues/67","repository_url":"https://api.github.com/repos/spring-projects/spring-hateoas","labels_url":"https://api.github.com/repos/spring-projects/spring-hateoas/issues/67/labels{/name}","comments_url":"https://api.github.com/repos/spring-projects/spring-hateoas/issues/67/comments","events_url":"https://api.github.com/repos/spring-projects/spring-hateoas/issues/67/events","html_url":"https://github.com/spring-projects/spring-hateoas/issues/67","id":14055625,"number":67,"title":"ResourceSupport.getId() shadows properties named \"id\" on content objects","user":{"login":"Laures","id":2330594,"avatar_url":"https://avatars.githubusercontent.com/u/2330594?v=3","gravatar_id":"","url":"https://api.github.com/users/Laures","html_url":"https://github.com/Laures","followers_url":"https://api.github.com/users/Laures/followers","following_url":"https://api.github.com/users/Laures/following{/other_user}","gists_url":"https://api.github.com/users/Laures/gists{/gist_id}","starred_url":"https://api.github.com/users/Laures/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Laures/subscriptions","organizations_url":"https://api.github.com/users/Laures/orgs","repos_url":"https://api.github.com/users/Laures/repos","events_url":"https://api.github.com/users/Laures/events{/privacy}","received_events_url":"https://api.github.com/users/Laures/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":22,"created_at":"2013-05-07T15:43:25Z","updated_at":"2016-11-02T12:31:22Z","closed_at":"2016-11-02T12:31:22Z","body":"because of the naming. because of a known bug (that concernes jsonUnwrap) in jackson it is not possible to create an \"id\" property on model objects that are wrapped into resources. the resourceSupport.getId will shadow the model property getId.\n\nyou can successfuly serialize such resources but you can not deserialize them. jackson will simply ignore the \"id\" property because it is annotated with jsonignore on the resourcesupport class.\n\nthe easy workaround is to rename the model property into something other than \"id\". but thats a bit annoying.\n"},"comment":{"url":"https://api.github.com/repos/spring-projects/spring-hateoas/issues/comments/257851156","html_url":"https://github.com/spring-projects/spring-hateoas/issues/67#issuecomment-257851156","issue_url":"https://api.github.com/repos/spring-projects/spring-hateoas/issues/67","id":257851156,"user":{"login":"olivergierke","id":128577,"avatar_url":"https://avatars.githubusercontent.com/u/128577?v=3","gravatar_id":"","url":"https://api.github.com/users/olivergierke","html_url":"https://github.com/olivergierke","followers_url":"https://api.github.com/users/olivergierke/followers","following_url":"https://api.github.com/users/olivergierke/following{/other_user}","gists_url":"https://api.github.com/users/olivergierke/gists{/gist_id}","starred_url":"https://api.github.com/users/olivergierke/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/olivergierke/subscriptions","organizations_url":"https://api.github.com/users/olivergierke/orgs","repos_url":"https://api.github.com/users/olivergierke/repos","events_url":"https://api.github.com/users/olivergierke/events{/privacy}","received_events_url":"https://api.github.com/users/olivergierke/received_events","type":"User","site_admin":false},"created_at":"2016-11-02T12:31:22Z","updated_at":"2016-11-02T12:31:22Z","body":"@sshcherbakov — There are a couple of misconceptions here: The backend domain object doesn't have anything to do with the way `ResourceSupport` works. So as soon as your domain object exposes the identifier under a different property name, you'll get the ID exposed. I guess you could even create your own subclass of `ResourceSupport` and override `getId()` and expose it again by annotating the method with `@JsonProperty`. I'd still argue that we shouldn't make it easy to do the wrong thing.\r\n\r\nSpeaking of which: Feign actually falls exactly into that category as it's basically based on baking URI structures into clients which is fine if you think of JSON via HTTP, but not REST. Spring HATEOAS whole point is to be opinionated about things — as is Spring Data REST — and make sure you're not violating core REST principles when using it. Why else would you want to use the library in the first place? If all you're interested in is CRUD via JSON over HTTP, then both libraries are just the wrong tools. That's basically like walking into a restaurant and then wanting the check to cook like you're used to.\r\n\r\nI am gonna close this for now as I find myself repeating the same arguments over and over again and all that comes up are basically the same, already answered questions."}}
{"actor":{"display_login":"olivergierke"}}