...
> 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. John =:->
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
