Skip to content

Instantly share code, notes, and snippets.

@mythz
Created November 22, 2011 18:02
Show Gist options
  • Save mythz/1386381 to your computer and use it in GitHub Desktop.
Save mythz/1386381 to your computer and use it in GitHub Desktop.
Difference between an RPC-chatty and message-based API

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:

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:

@OndrejValenta
Copy link

Is this still valid at 2019? I'm not questioning this article or anything in it, I'm just asking if something has changed or if there was a development of the philosophy, technology or something else in ServiceStack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment