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:

public class Customers { int[] Ids; string[] UserNames; string[] Emails; } public class CustomersResponse { Customer[] Results; } public class CustomersController : ApiController { public CustomersResponse GetCustomers([FromUri] Customers request) { //some logic return new CustomersResponse(); } }

ServiceStack hydrates the same model via PathInfo, QueryString (that also allows complex object graphs), FormData / RequestBody, SOAP and MQ endpoints for free (i.e. with the same service). You can also easily provide a HTML representation by just adding a Razor view with the same name as the Request or Response DTO (i.e. no-touch development).

There's built-in support to delegate it to a different service: in the same AppDomain instance with ResolveService or a remote instance by dropping it into a ServiceClient (or MQ). There's built-in mapping and our serializers are fast, resilient and versionable. We're more idiomatic with C# as by default Exceptions are auto converted into ideal Http Status codes (that's configurable) and hydrated into a typed Exceptions in remote C# clients.

You also get and end-to-end API without any code-gen or custom routes defined (i.e. by using the pre-defined fallback routes).

IOTW ServiceStack provides a much better story for supporting message-based HTTP, SOAP or MQ services.

mythz/RpcVsMessages.md