<div class="gmail_quote">On Mon, Aug 2, 2010 at 1:40 PM, Eric Day <span dir="ltr"><<a href="mailto:eday@oddments.org">eday@oddments.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hi Jorge, Michael,<br>
<br>
Yeah, this is pretty much what I had in mind. Beyond having services<br>
that get called out from APIs, the implementation within the projects<br>
should not be specific as well. For example, there should be a generic<br>
auth API that can be used across projects, but this could be backed by<br>
LDAP, MySQL, or something else. This keeps things modular for future<br>
changes and also makes testing easy since you can load in hard-coded<br>
modules that don't depend on having a setup.<br></blockquote><div><br></div><div>Yep, I completely agree that APIs should be interfaces to different service implementations (including a stub or mock implementation for testing.)</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
>    I would definitely advocate for using REST for *all* our service<br>
>    communication unless there were a really strong case for doing otherwise<br>
>    in an individual case.  Makes the system more consistent, makes it easy to<br>
>    interface with it if you need to, makes it easy to write a unified logging<br>
>    module, lets us easily tcpdump the internal traffic if we ever needed to,<br>
>    etc.  Putting a language binding on top of that is just added convenience.<br>
<br>
</div>Agreed, mostly. I would advocate using the native API/protocol, and<br>
when one is not available or we are starting from scratch, fall back<br>
to REST. For example, there is no reason to force a queuing service<br>
like RabbitMQ to speak REST if AMQP is already supported. This means<br>
abstracting at that API layer and not the protocol layer as much<br>
as possible.<br></blockquote><div><br></div><div>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.</div>

<div><br></div><div>Michael</div></div>