It looks like the service interfaces all expect to be invoked directly from an API handler (they only have Cmds for parameters). For example, QueryService/QueryManagerImpl.searchForServers() takes a ListHostsCmd. This ListsHostsCmd can only be created by invoking the listHosts API. If it had public setters, then the command could be instantiated and execute() could be called directly, but that wouldn't be working at the service interface level.
Am I missing something here or is this not the service interface you meant? -Chris On Jul 15, 2013, at 12:29 AM, Chiradeep Vittal <chiradeep.vit...@citrix.com> wrote: > APIs should call the service interface directly and not call other APIs. > > On 7/12/13 1:40 AM, "SuichII, Christopher" <chris.su...@netapp.com> wrote: > >> Er, I should have mentioned that it is not as easy as simply invoking one >> API command from another since all the CS API commands have private >> @paramenter members. Because of this, I cannot simply instantiate a >> command, populate it with the parameters and call execute() on it. >> >> -Chris >> >> On Jul 11, 2013, at 4:09 PM, Chris Suich <chris.su...@netapp.com> >> wrote: >> >>> I'm writing an API plugin that needs to consume an API that already >>> exists in CS. The only way I can find to do this would be to send the >>> REST/HTTP request from my plugin, but I'm hoping there is an easier way. >>> Since both plugins are on the same Java classpath they have the ability >>> to invoke each other. >>> >>> Is there a simple way to do this that I'm missing? >>> >>> -Chris >> >
