Using JPA entities directly in the REST resources is obviously not proving to be of much help:

• It leads to problems when working with cyclic dependencies, as seen in FORGE-606. Using @JsonIdentityInfo to resolve this has lead to further problems on the client side due to the lack of support in JavaScript clients to handle JSON object references out of the box.
• It requires the entire object graph to be eagerly fetched and made available during the serialization process. During deserialization, JPA merges could result in incorrect behavior since merges of object graphs depend on whether the collection was previously fetched or not. Merges are not expected to occur by spec, unless the collection was fetched. See HHH-4135 and HHH-5187 for some details on Hibernate, with differing behavior in EclipseLink.
• It requires manipulation of the relational associations across entities to modify the resource representations, thus lacking separation of concerns.
• It provides no control over the depth of the object graph to be serialized. Annotations like @JsonIgnore are required to be placed on JPA entities which does not aid in separation of concerns. Custom serializers/deserializers offer little benefit concerning standards since they requires compilation against specific versions of the JSON libraries like Jackson for every container that is to be supported.

Therefore it is proposed to have the REST plugin create DTOs for representing the state of the JPA entities in the REST resources.