Difference between an RPC-chatty and message-based API

	public interface IService
	{
	  Customer GetCustomerById(int id);
	  Customer[] GetCustomerByIds(int[] id);
	  Customer GetCustomerByUserName(string userName);
	  Customer[] GetCustomerByUserNames(string[] userNames);
	  Customer GetCustomerByEmail(string email);
	  Customer[] GetCustomerByEmails(string[] emails);
	}

contrast with an equivalent message based service:

	public class Customers {
	   int[] Ids;
	   string[] UserNames;
	   string[] Emails;
	}

	public class CustomersResponse {
	   Customer[] Results;
	}

Any combination of the above can be fulfilled by 1 remote call, by the same single web service - i.e what ServiceStack encourages :)

Fewer and more batch-full services require less maintenance and promote the development of more re-usable and efficient services. In addition, message APIs are much more resilient to changes as you're able to safely add more functionality or return more data without breaking or needing to re-gen existing clients. Message-based APIs also lend them better for cached, asynchronous, deferred, proxied and reliable execution with the use of brokers and proxies.

Comparatively there is almost no win for a remote RPC API, except to maybe hide a remote service even exists by making a remote call look like a method call even though they're millions of times slower, leading new developers to develop in-efficient, brittle systems from the start.

Related patterns:

http://msdn.microsoft.com/en-us/library/ff649585.aspx (Data Transfer Object)
http://msdn.microsoft.com/en-us/library/ff650101.aspx (Service Gateway)

The above patterns inspired ServiceStack (and why it was created). Unfortunately MS doesn't listen to their own advice here and encourages the RPC model with WCF.

These recommendations were originally inspired by Martin Fowler:

mythz/RpcVsMessages.md