openstack team mailing list archive

[Michael Gundlach <michael.gundlach@xxxxxxxxxxxxx>]

On Mon, Aug 2, 2010 at 1:40 PM, Eric Day <eday@xxxxxxxxxxxx> 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