jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ignasi <ignasi.barr...@gmail.com>
Subject Re: Design Help for Delegate APIs
Date Sat, 29 Jun 2013 15:06:02 GMT
I tend to split the api in delegates when they are big enough and present
different functional areas.

In chef, for example, there are several resource types, but there are only
about 3-4 operations available (mostly CRUDs) on each one, so they are all
in the ChefApi. I think it makes more sense than having I many apis with
few methods. In Abiquo, however, resources are more complex and there is an
api for each functional area (not necessarily one per resource).

In the end it is about making them predictable and understandable to the
end users.

I don't know if we have a convention, but this is how I tend to implement
El 28/06/2013 17:20, "Jeremy Daggett" <jeremy.daggett@gmail.com> escribió:

> Greetings,
> I am working on a newer implementation of the Swift API in openstack-swift,
> so that all of the known Swift features are exposed via the jclouds API.
> What is the best approach for the newer style delegate APIs? Should I base
> the interface explicitly on the resource type? In the Swift Account API, in
> order to list containers we have:
> FluentIterable<? extends Container> listContainers();
> FluentIterable<? extends Container> listContainers(ListContainersOptions...
> opts);
> However, the new style APIs would indicate that I would expose this in the
> Container API as:
>  FluentIterable<? extends Container> list();
> FluentIterable<? extends Container> list(ListContainersOptions... opts);
> This pattern would also apply to the Container/Object API where we would
> push the listObject(..) call one interface down. Then the Container API
> would have list(), and list(ListContainerOptions) and listObjects would
> move to the ObjectApi as list().
> WDYT? What is the preferred approach here? Thx.
> /jd

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message