Community/Collection Hierarchy in DSpace 7 REST

README.md

1. See https://jira.duraspace.org/browse/DS-3531
2. See https://jira.duraspace.org/browse/DS-3532
3. How do we embed data in an object that should only be populated on request? Or, does it need to be a separate object?

NavigableObjectRest.java

/*
 * Only items, collections, communities, and sites have handles, so handle should move out to a separate object.
 * Every navigable item has a breadcrumb trail.
 */
NavigableObjectRest extends DSpaceObjectRest {
  private String handle;
  
  //Is this embedded - too slow
  //Is this retrieved through a separate endpoint - cumbersome
  //Is this embedded but populated only on request - how do we represent that in our framework
	private List<NavigableObjectRest> breadcrumbList;
  
}


/*
 * Site and Community objects have descendant hierarchies
 */
HierarchicalObjectRest extends NavigableObjectRest {
  //Is this embedded - too slow
  //Is this retrieved through a separate endpoint - cumbersome
  //Is this embedded but populated only on request - how do we represent that in our framework
  private List<NavigableObjectRest> descendandHierarchyList;
}

my idea is to have all the objects ready to hold as much information as possible. This mean that the parent object should be an attribute of our REST objects. We need to define a way to allow lazy loading in a similar way that the Hibernate framework does with the persistent entities.
We should use annotation to provide to our framework enough information to lazy load the relation when required. This could in turn rely on hibernate lazy-loading capabilities or trough direct invocation of dedicated retrieve methods.

Request should express interest for optional information specifying a "projection". Both the converter and the repository should be aware of the projection so to

• lazy load the required information (converter responsibility)
• optimize the retrieve of the information avoiding lazy load as much as possible

Projection should be defined as

• additional information to include
• information to hide

where the "base set" for each rest entity is defined. We could introduce an "optional" annotation to define which information are not part of the "base set".

@abollini, It is helpful to know your thoughts for optional/lazy loaded properties. Currently, we keep data in _embed and in _links. We probably also need _optional to house optional properties. If you look at the 3rd gist (https://gist.github.com/terrywbrady/9fddc7cd31e5d975b503c97a7330aa6b) I posted on Friday, I started to brainstorm how we might want to access breadcrumbs and hierarchy. I would be curious how that data would be represented with lazy loading.

I created a Jira ticket to track this as well. https://jira.duraspace.org/browse/DS-3533