The admin API will be implemented as a separate topology.  This will allows for a separate authentication and authentication and authorization from normal topologies/clusters.  The admin topology will be called admin.  This may conflict with existing customer topologies but that could be addressed by the customer renaming the admin topology.

<topology>
  <gateway>
    ....
  </gateway>
  <service>
    <role>ADMIN</role>
  </service>
</topology>

 Note: The <url> element is not required as this will be an "internal" service.

The internal service will likely be implemented as a Jersey based dispatch based on the module gateway-provider-jersey. 

Open Questions/Issues

• In order for SLA to be used directly separate services would be required to support different ATZ policy.
• Does this highlight a need to have the service unique portion of the URL exposed in the topology file (e.g. webhdfs, hive, admin, etc?)
• Does the work on versioned services need to come into play here?