Charm store API proposal, new version

[Richard Harding]

On Wed, 16 Jul 2014, John Meinel wrote:

> ...
>
>
> > To echo what Aaron says, in any distributed system, it is almost always a
> > mistake not to design for bulk api calls. Even if you don't think they are
> > needed for the initial use cases, they will almost always be needed at some
> > point later. It is trivial to use a bulk call with a single value, but it
> > is not
> > trivial to go the other way. This topic has been discussed previously in
> > the
> > juju-core space. I had thought that William had (correctly) mandated the
> > bulk
> > calls were to be used for our distributed apis.
> >
> >
> Just tossing in my agreement here. If you just provide single resource
> endpoints, it makes it really hard to ever improve your request efficiency.
> And while *current* clients may only ever pass one, if it is meant to be an
> API that we will use "for a long time" we should try to keep in mind future
> proofing.
>
> I will agree that we went a little overboard internally. We knew that the
> Client api should have been bulk but wasn't so we wrote all of the internal
> APIs as bulk even though it isn't really able to be used. However, if we
> can update Client, then at least things are consistent and useful across
> the board.
>
> Anyway, I do know that Launchpad suffered a lot having been written as
> one-by-one and it made it really hard to write efficient clients that
> interacted with LP's web API. It would be good to at least allow for the
> possibility of people wanting to build external consumers.

I'm not against having any bulk api calls but we've got a handful of
clients and the one use case we've found for them is Aaron's work which I
think we can better address with our current scheme anyway as he only
needed the bulk api call to get data he'd already have on hand.

I'm just trying to argue that going with a default bulk api endpoint setup,
when all the current clients are using the single, seems like changing the
current api from v3 to v4 massively without a use case driving it.

Please help us find use cases by clients we're not addressing. Aaron's
feedback has helped us find a pair of missing bits of data to add to the
spec and we appreciate it.

On a side note, on bulk calls in general, I wonder if there's a difference
in a resource based api vs something with state? I've never really run into
many bulk apis out there with sites I've interacted with like github,
flickr, or delicious. I wonder if it's due to the fact that resource based
services you tend to either search for something (and get results in bulk)
or be looking at a single resource in detail. In juju-core's updates to the
bulk api, were those driven by state-related calls or by resource
information calls? I don't have deep enough knowledge as to what drove the
juju-core  api-ageddon.


--

Rick Harding