Refactor API so it becomes simpler and more consistent

12329
Reporter: mdoering
Type: Epic
Summary: Refactor API so it becomes simpler and more consistent
Priority: Major
Status: Open
Created: 2012-11-16 12:47:38.041
Updated: 2014-01-20 10:57:22.297
        
Description: The api has been designed by looking at the 3 main parts (registry, checklistbank and occurrence) individually and therefore lack some overall consistency.
A main refactoring is proposed to adress this and include various enhancements in one go. The currently open api issues are listed in http://dev.gbif.org/issues/secure/IssueNavigator.jspa?mode=hide&requestId=11103.
The list of known inconsistencies that should be addressed includes:

 - new Tag API
 - make sure we use dataset & constituent everywhere. CLB uses checklistKey and dataset for a constituent. Messages use datasetUuid instead of datasetKey
 - flatten out class hierarchies in registry and checklstbank creating interfaces for some used base classes instead
 - rethink some registry class names. Would an outsider understand them? In particular consider:
   - NetworkEntity -> RegisteredEntity
   - NetworkEntityComponent -> RegisteredEntityRelated or for some cases DatasetRelated?
 - streamline 3 Identifier classes, consider converting NameUsageComponent base class into an interface
 - similarily streamline Image classes
 - add a PhysicalCollection registry class?
 - EML issues: http://dev.gbif.org/issues/secure/IssueNavigator.jspa?mode=hide&requestId=11102]]>