public
Last active

Difference between an RPC-chatty and message-based API

  • Download Gist
RpcVsMessages.md
Markdown

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:

Thanks you for taking the time to write all this stuff. Wow, this is great.

You're right :). This a whole new world of awesome.

I know it isn't the Microsoft prescribed way, but can't you do the same thing with WebAPI? I'm asking because I have done this as an example and am not sure if I am over simplifying or not realizing something else that ServiceStack is doing different.

    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.

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.