Odd that Web API was chosen over servicestack.net given 'Messaging-based web services' has been the fundamental concept behind servicestack.net for several year

Odd that Web API was chosen over servicestack.net given 'Messaging-based web services' has been the fundamental concept behind servicestack.net for several years which has always promoted a message-based design as a first-class concept where all its features are built around message-based DTOs to take advantage of the benefits of messaging: https://github.com/ServiceStack/ServiceStack/wiki/Advantages-of-message-based-web-services https://github.com/ServiceStack/ServiceStack/wiki/Advantages... The pipeline described in the article is very similar to ServiceStack's request pipeline (https://github.com/ServiceStack/ServiceStack/wiki/Order-of-Operations https://github.com/ServiceStack/ServiceStack/wiki/Order-of-O...) where Global, Service and Action Request and Response Filters allows composition of custom logic to be selectively applied at different levels of granularity and priorities. ServiceStack's message-based design is what allows it to provide .NET's most succinct, end-to-end typed API without any code-gen or post-build steps. You're able to re-use the code-first DTO's services were defined with, as-is, inside clients. This has many benefits, message-based DTO designs are more resilient, and support the natural evolution of services. It's inherently simpler with less friction as client and server call-sites have symmetrical parity as the same DTO the client sends is transparently hydrated into services on the server. Message-based design's are also inherently more re-usable as they encapsulate services in their most re-usable form, which is what allows the same service in ServiceStack to be called via HTML/Web, REST, SOAP, MQ endpoints in JSON, XML, SOAP 1.1/2, HTML, CSV, JSV, MessagePack and Protocol Buffers formats with no effort.