In an ideal world I would be able to do all three. I'd love to be able to represent my domain models as json that I can then manipulate from the client, return to the server, extract into DOs, and then recognize persisted objects based on whether they have an ID or not. I'm afraid that's a bit too simplistic though and I'm dealing with too many disparate systems to make it work automagically.
Practically what I what like is to standardize my REST api so that manipulation of child objects/relationships takes place on a different api call. And then make parent object creation/manipulation ignore relationship sets and child objects all together.
EX - Creating a new Guild -> POST site/guild
- Add a game to a Guild -> PATCH site/guild/3/game
- Remove a game from a guild -> DELETE site/guild/3/game/2
This way I don't have to deal with detecting child collections/object as new or existing(or at all, really). This would also solve the problem I'm having in this thread. The problem with that approach though is that json4s extracts the entire object and there's no easy way to tell it to ignore property X when serializing/extracting. (There is a way but it's boilerplate heavy, promotes tight coupling, and time-consuming to write.)
Without using the hard method my other alternative is to write default values for all my DOs parameters so json4s doesn't get mad when extracting new objects from JSON as well as manually extract all object properties and then manually copy them into a retrieved persisted entity based on the ID from the rest call when manipulating them. (which is just as time-consuming and coupling as the first method)