Design Help for Delegate APIs

[Jeremy Daggett <je...@gmail.com>]

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

Re: Design Help for Delegate APIs

[Ignasi <ig...@gmail.com>]

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
them.
El 28/06/2013 17:20, "Jeremy Daggett" <je...@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
>