Difference between an RPC-chatty and message-based API

RpcVsMessages.md

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:

• http://martinfowler.com/eaaCatalog/dataTransferObject.html
• http://martinfowler.com/eaaCatalog/gateway.html
• http://martinfowler.com/eaaCatalog/remoteFacade.html

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

Then you might also like :) https://github.com/ServiceStack/ServiceStack/wiki/Advantages-of-message-based-web-services

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.

Agree, RPC-chatty is awful, but we can do the same with WCF, for example with Nelibur. As for me the biggest problem for all .Net web service frameworks is the simplest way is wrong way. A framework should let do correct things simple and wrong difficult. As for me ServiceStack or Nelibur lets keep correct simple instead of "raw" .Net web service frameworks (WCF, WebAPI, WCF DataServices etc)

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.