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;
}

@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