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" <[email protected]> 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 >
