On Mon, Aug 2, 2010 at 1:40 PM, Eric Day <e...@oddments.org> wrote: > Hi Jorge, Michael, > > Yeah, this is pretty much what I had in mind. Beyond having services > that get called out from APIs, the implementation within the projects > should not be specific as well. For example, there should be a generic > auth API that can be used across projects, but this could be backed by > LDAP, MySQL, or something else. This keeps things modular for future > changes and also makes testing easy since you can load in hard-coded > modules that don't depend on having a setup. >
Yep, I completely agree that APIs should be interfaces to different service implementations (including a stub or mock implementation for testing.) > > I would definitely advocate for using REST for *all* our service > > communication unless there were a really strong case for doing > otherwise > > in an individual case. Makes the system more consistent, makes it > easy to > > interface with it if you need to, makes it easy to write a unified > logging > > module, lets us easily tcpdump the internal traffic if we ever needed > to, > > etc. Putting a language binding on top of that is just added > convenience. > > Agreed, mostly. I would advocate using the native API/protocol, and > when one is not available or we are starting from scratch, fall back > to REST. For example, there is no reason to force a queuing service > like RabbitMQ to speak REST if AMQP is already supported. This means > abstracting at that API layer and not the protocol layer as much > as possible. > Oh, yeah, that's a good clarification. I guess I was only thinking of stuff we wrote ourselves, but forgot that when you talk to memcached, you of course use memcached's protocol. Michael
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
