回答:
ServiceStackプロジェクトの主任メンテナーとして、私はServiceStackの利点とメッセージベースの設計の多くの自然な利点をよく理解しています。
ServiceStackは、摩擦のないリモートサービスの正しい設計と実装を促進するという単一の目標を掲げ、2008年からOSSが実行するプロジェクトとして設立されました。
究極のシンプルさを追求して、それはシンプルでエレガントなコアを中心に構築されています -ほとんどの機能はコントローラーではなくモデルに自然にバインドされています-これはMVC、WebApi（およびMicrosoftが作成した他のすべてのWebサービスフレームワーク）と同じです）。
メッセージベースの設計を採用すると、リモートサービスに優れたアプローチが提供され、拡張性が高く、脆弱性の少ないサービスが促進され、アクセスと呼び出しのパターンが簡素化され、その他の多くの自然なメリットが無料で得られます。
中核的な使命として、目に見えない非侵入型のAPIを維持し、今日の.NETまたはWebサービスの開発者にはまだ馴染みのない新しい概念や人工の構成要素の導入を回避することを目指して、あらゆる段階で複雑さと戦います。
例として、IService<T>サービスの実装は、自動配線された依存関係を持つ単なる標準のC＃クラスです。薄く軽量なラッパーを使用して、コアランタイムのIHttpRequestおよびIHttpResponseタイプの周りに一貫性のある統一されたAPIを提供します。また、基盤となるASP.NETまたはHttpListenerのRequestクラスとResponseクラスへのアクセスを許可するため、ServiceStackを使用するときに制限を受けることはありません。
ServiceStackとWCFが促進する対照的なAPIスタイルの概要を以下に示します。WebApiはREST-ful API設計を促進するという点でWCFとは異なります。2つの間の例については、これはServiceStackとWebApiの両方で同じサービスを記述した唯一の既知の例です。
ServiceStackは、シンプルさ、パフォーマンスに重点を置いており、可能な限り慣用的なC＃でMartin Fowlersのリモートサービス設計パターンを採用することを中心としたWeb /リモートサービスのベストプラクティスを推進しています。
Facadeパターン -これまであなたは、プロセスの境界を越えて通信batchful、粗粒のインタフェースの使用を示唆しています。
DTOパターン（MSDN） -あなたのWebサービス応答のワイヤフォーマットを生成するための専用のPOCOSの使用を規定。
ゲートウェイ・パターン（MSDNクライアントゲートウェイ/ DTOモデルとサービス・インターフェイス階層間、クライアントとサーバーの通信をカプセル化します）。
これらのパターンは、懸念事項を明確に分離し、摩擦のない反復的な開発経験を保証します。
中核のServiceStack Webサービスは、依存関係のない自動配線された純粋なC＃IService<T>インターフェースを中心としており、クリーンなPOCOを使用して独自の要求および応答DTOでWebサービスコントラクトを完全に自由に定義できます-ServiceStackのAPIを実質的に非表示かつ非表示にする-invasive、つまりC＃サービスロジックを抽出してServiceStackホストの外部で実行するのは簡単です。
この要点は、ServiceStackの1つのC＃.csクラスで得られる良い例です。
RestServiceBaseクラスとServiceBaseクラスは、可能な限り最大限の再利用のためにカスタムC＃ロジックをホストすることを目的としています。たとえば、DTOファーストの設計により、同じC＃サービスをMQホストでホストおよび実行できる遅延実行およびプロキシ実行が簡単に可能になります。これはIMessageService、RedisMQホストのようなものを登録し、/asynconewayエンドポイントを介して（つまりclient.SendOneWay()、C＃クライアントで）サービスを呼び出すとどうなるかです。
Nortwind CustomerDetailsサービスの例にあるbase.ResolveService<T>()ように、選択したサービスの自動接続インスタンスを返すメソッドを使用して、複合サービスを簡単に委任して作成することもできます。
var ordersService = base.ResolveService<OrdersService>();
var ordersResponse = (OrdersResponse)ordersService.Get(
new Orders { CustomerId = customer.Id });
ほとんどの場合、ServiceStackはほとんどのC＃オブジェクトを期待どおりにシリアル化します-返される可能性のある型のリストを以下に示します（この回答から）：
次のタイプは変換されず、応答ストリームに直接書き込まれます。
カスタムHTTPヘッダーサポートの例は、このCORSの例で確認できます。このCORSの例では、HTTPヘッダーをグローバルに、またはサービスごとに構成できます。
ここで詳しく説明されている ServiceStackでHTMLを返すための複数のオプションがあります。
弾力性と高速シリアライザは、高速な応答時間を確保するためのAPIで第一に重要であるとServiceStackが含まれる理由は、既存のクライアントを破壊しないバージョン管理API for .NETの最速テキストシリアライザ有効にするにはNuGetオプション付き@marcgravellをのプロトコルバッファ（.NETの最速のバイナリシリアライザ）。
ServiceStackのテキストシリアライザーは非常に復元力があり、エラーなしで極端なバージョン管理に耐えることができます。
ServiceStackの独断的な性質により、コード生成なしのSync / Async C＃/。NETおよびAsync Silverlightクライアントの組み込みサポートにより、エンドツーエンドで高速で型指定された簡潔なWebサービスAPIが可能になります。
var response = client.Send<HelloResponse>(new Hello { Name = "World!" });
client.SendAsync<HelloResponse>(new Hello { Name = "World!" },
r => Console.WriteLine(r.Result), (r, ex) => { throw ex; });
純粋なJSONを返すだけなので、jQueryを使用したJSクライアントの例など、他のHTTPクライアントでも簡単に使用されます。
$.getJSON("http://localhost/Backbone.Todo/todos", function(todos) {
alert(todos.length == 1);
});
すべてのC＃/。NET ServiceClientは同じインターフェイスを共有するため、高度なテストとスワップが可能になり、同じユニットテストでXML、JSON、JSV、SOAP統合テストとしても機能させることができます。
フリクションフリーでクリーンな開発体験を提供するという使命に基づいて、ServiceStackには型付き検証とエラー処理が組み込まれており、C＃例外をスローしたり、組み込みのFluent検証を使用したりすると、Webサービスクライアントで構造化された型付きエラーに簡単にアクセスできます、例：
try {
var client = new JsonServiceClient(BaseUri);
var response = client.Send<UserResponse>(new User());
} catch (WebServiceException webEx) {
/*
webEx.StatusCode = 400
webEx.ErrorCode = ArgumentNullException
webEx.Message = Value cannot be null. Parameter name: Name
webEx.StackTrace = (your Server Exception StackTrace - if DebugMode is enabled)
webEx.ResponseDto = (your populated Response DTO)
webEx.ResponseStatus = (your populated Response Status DTO)
webEx.GetFieldErrors() = (individual errors for each field if any)
*/
}
JavaScriptでエラーを消費するのを簡単にするために、軽量のss-validation.js JavaScriptライブラリを使用して、1行のコードで応答エラーをHTMLフォームフィールドに簡単にバインドできます。SocialBootstrapApiのプロジェクト例は、この良いデモを提供します。
ServiceStack MVCパワーパックの再書き込みと修正そのための代替とASP.NET MVCとの不振の解決策の多くは壊滅セッション ICacheClientとISessionのAPIの独自のクリーンと依存関係のない実装ととキャッシュのXML-邪魔ASP.NETプロバイダ。
ServiceStackには、新しく、よりクリーンな認証および自動化プロバイダーモデルも含まれており、さまざまなAuthProviderが組み込まれています。
認証モジュールは完全にオプションであり、クリーンなICacheClient / ISession APIとOrmLiteに組み込まれているため、セッションをメモリ、Redis、またはMemcachedに保存でき、ユーザー認証情報は、SQLServer、MySql、PostgreSQL、SqliteのOrmLiteでサポートされているRDBMSに保持されます。 RedisデータストアまたはInMemory（開発/テストに便利）も同様です。
ServiceStackは非常によく文書化されており、フレームワークに関するほとんどの情報はGitHub wikiでホストされています。フレームワークの他の部分（シリアライザ、Redis、OrmLiteなど）のドキュメントは、servicestack.net / docs /にあります。
ServiceStack.ExamplesながらプロジェクトはServiceStackのライブデモやスターターテンプレートのすべてのソースコードを提供SocialBoostsrapApiプロジェクトは、 Twitterのブートストラップテンプレートに基づいServiceStackとMVCとBACKBONE.JS単一ページのアプリケーションを開発するの偉大な出発点を提供します。
上記に加えて、情報の宝庫は、近年かなり拡大しているGoogleグループに含まれています。
ServiceStackは、ASP.NETおよびHttpListenerホストで実行される.NET 3.5フレームワークであり、.NETまたはMonoでホストできます（雑学：www.servicestack.netはCentOS / Monoによって提供されています）。これにより、ServiceStack Webサービスを次のいずれかでホストできます。
ServiceStackは、オープンソースで積極的に開発されているオープンソース開発モデルを強く信じており、創業以来、常にリベラルなOSSライセンス（New BSD）の下でホストされてきました。現在、47人以上の開発者から寄稿を受けており、現在、GitHubで3番目に多く視聴されているC＃プロジェクトに参加しています。
最大の欠点は、Microsoftによって開発されなかった（または利用可能なオプションとしてリストされていた）他のほとんどのOSS .NETプロジェクトでも同じだと思います。これは、フレームワークを評価するときに最初の選択肢になることはめったにないことを意味します。ほとんどの採用者は、ServiceStackを最後の手段として評価するだけで、WCFに課せられた摩擦と脆さ、または優先されるMicrosoft Stackのパフォーマンスに不満を感じます。
ServiceStackは、メーリンググループのポジティブな感情によって目に見えるものとしてそれを評価したほとんどの人々から提供されたポジティブなフィードバックで非常に好評です。今年の時点で、@ ServiceStackの Twitterアカウントは、お気に入りの言及やフィードバックを追跡しています。
コミュニティリソースのwikiページには、より多くのServiceStackについて野生で投稿、ポッドキャスト、プレゼンテーション、要旨などをブログにリンクを持つを見つけるのに良い場所です。
考慮する必要がある新しい主な違いがあります-ServiceStackはv4から無料で使用できなくなりました。 SSプロのかなり明確な答えがあるので、Web APIのカップルを捨てたかった
プロの：
コンの：
付随的なメリット
（Web APIに利点がある、または私が追加できる長所/短所がある理由を追加して、以下にコメントを残してください）
ServiceStackについてはあまり言えませんが、Web APIには多くの優れた機能があり、現在はバージョン2です。
Web APIでできることのいくつか：
asyncとawait。ServiceStackのお客様として、ここで私にとってServiceStackのプロが最も重要です。
https://github.com/ServiceStack/Issues/issues/606
そう。バグが見つかり、バグが特定され、バグが修正されました。同日。抜群のサポート！
私がSSを使用して1年になりますが、それはすべて素晴らしいです。ORMLiteは純粋な魔法です。awfull MySQL DBを再マッピングして、モバイルアプリに統合することができました。データベースに変更がないため、別のアプリのphpバックエンドで使用されています...
神話はサポートと説明に関する例です。アプリの設計とメンテナンスの簡素化に関する私の知識をアップグレードしました。是非お試しください。
また、SSをWebAPIと比較しないでください。それは十分ではありません、SSはあなたのツールボックスにより多くのものをもたらします。ServiceStack.Textも優れたAutomapperです。