This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AFAIK the id isn't send for RESTful reasons... in REST the id of a resource is the URI of the resource not the id of an entity... the client also shouldn't know anything about that... there might be a extension mechanism in future, so you can adjust that by adding the id to the response for client-handling issues. Maybe you can live with the uri as well (as i do now).

The null valued fields are skipped by default by jackson... one can configure that, but the RestExporterController (or whatever this is named) has a private member for its very own ObjectMapper, so you cannot configure that by now...

Hopefully in the future there will be an option for those who want pass the id/pk to the client. When working with client side JavaScript frameworks e.g backbone.js, the id field is needed for the basic backbone rest setup.

When i was testing data rest the only way i worked around the id problem was using @PostUpdate in the model entity to alias the primary key into a another column that was included in the serialized output.

Other issues i had with data rest were:
The incoming null properties are not processed at all, so nulling a property isn't possible

@Transient properties are not included in the serialized response

When updating a entity there is no way to have any non persisted attributes in the incoming json. In some cases it is necessary to have some extra data in the json. e.g. when updating user's password through rest, it would be nice to have a transient property, boolean updatePassword in the data. That could be used for detecting if the incoming user entity includes a new plain text password that should be put though password encoder before persisting.