Separate Document From Resource

[lukesleeman]

We have found the current model, where there is a bidirectional link between Resource and Document to be very limiting and would like to open up a discussion about removing the link from Resources back to their parent document. We understand that this would be a fairly considerable design change - perhaps this something best targeted at moshi-jsonapi 3.0

Currently a Document stores its data and included resources and each Resource has a (nullable) link back to the Document that contains it via the _doc field. The link from Resource to Document is used to resolve HasOne and HasMany. This link from Resource to Document has caused us number of issues:

• When serializing Resources, the Document gets serialized, which brings all of the included objects, which makes a huge mess.
• We want to be able to move Resource around between Documents. As an example a Document containing a list of Book objects may be fetched from the server. Later on we want to include one of the specific books in a new Document to be sent back to the server to perform an update. Under the current model this is hard.
• Resources can not be standalone objects, they will only 'work' when they are included in a Document. For example you may have a Book object, with a HasOne to an author. Book.setAuthor(Author author) will not work unless the Book also has a Document.
• It violates the Principle of least astonishment. It makes sense that a Document would contain Resources - this mirrors the json. But having a Resource which doesn't work unless it has a link back to its document is surprising. Particularly as we would like to treat our Resources like POJO's

Removing the link from Resource to Document will be tricky - in particular it will require a solution for HasOne and HasMany which currently look up their values from the resources Document. I hope with this issue to prompt some discussion of ways to solve some of these issues.

[kamikat]

Thanks for your advice. With changes made in 3.x, we're now have Document and Resource less coupling. Serialization/deserialization now starts from a document and ends with a document, that is, a more consistent and less astonishing interface. But I can't make sure if the new version meets your requirement.