私は ServiceStack に頭を悩ませようとしています。非常に優れたドキュメントがあると主張していますが、今のところそうではないようです。どのインターフェース/基本クラスを使用するか、およびそれらが何をするかを実際に述べているドキュメントはありますか?
ただ..たくさんの質問があり、ほとんど答えを見つけることができません..新しいAPI設計は、IReturnインターフェイスを実装するDTOの例と、サービスから継承するサービスを示しています-しかし、これが現在好ましい方法であるかどうかの説明はありません. IReturn の実装に必要な、POST/GET/etc の処理方法など。
リンクをいただければ幸いです。
はい、私はサンプルを持っていますが、たとえば、この IReturn インターフェイスには何もありません..とにかく、サンプルはドキュメントに勝ることはありません。
ServiceStackWebFrameworkのすべてのドキュメントはwikiにあります。
ServiceStackの新しいAPIは今週リリースされたばかりで、すでにすべての質問に対する回答が含まれています。私は戻ってそれらを完全に読みますが、あなたの質問に答えるスニペットを抽出します：
「新しいAPIの紹介」セクションは次のとおりです。
新しいAPI設計は、この単一の統合インターフェースを使用して、既存のIServiceとIRestServiceを簡素化します。
public interface IService {}
これで、RPCサービスとRESTサービスの両方のリクエストを1つのクラスで処理できるようになりました。このインターフェースは、ServiceStackが既存のサービスを検索、登録、自動配線するために使用するマーカーインターフェースとして使用されます。ServiceStackのプロバイダーに簡単にアクセスできる便利な具体的なサービスクラスも含まれています
ウィキの上部にある見出しは次のとおりです。
新しいAPIデザインには、既存のAPIに比べて多くの利点があるため、新しいWebサービスの開発に使用することをお勧めします。少し時間がかかりますが、古い例をすべて移植して、新しいAPIを自分たちで採用する予定です。古いAPIを引き続き好む理由の1つは、以前のアプローチで適用された厳密さを依然として必要とするSOAPクライアントとエンドポイントもサポートしたい場合です。
インスピレーションの見出しの下に次のように書かれています。
この提案の利点は、ServiceStackの既存のメッセージベースのセマンティクスにすでに完全に適合していることです。つまり、既存のコードベースを中断したり変更したりすることなく、記録的な速さで実装できました。その結果、既存のサービスと一緒に新しいサービスの作成を開始できるようになり、両方がシームレスに並行して機能し続けます。
「型付きC＃クライアントからのサービスの呼び出し」という見出しの下には次のようなものがあります。
DTOを（バイナリ形式のいずれかのソースで）コピーする通常のルートを使用して、クライアントに次のようなものがあるとします。
[Route("/reqstars")]
public class AllReqstars : IReturn<List<Reqstar>> { }
クライアントのコードは次のようになります。
var client = new JsonServiceClient(BaseUri);
List<Reqstar> response = client.Get(new AllReqstars());
これにより、/reqstarsルートへのGETWebリクエストが作成されます。カスタムルートがクライアントに存在しない場合、ServiceStackの事前定義されたルートの使用に自動的にフォールバックします。
最後に、以前のより明示的なクライアントAPIを使用することもできます（IReturn <>マーカーがない場合に最適です）。
var response = client.Get<List<Reqstar>>("/reqstars");
これらすべてのAPIには、必要に応じて代わりに使用できる同等の非同期機能があります。
APIドキュメント全体は、PostのGetがどのように機能するかを効果的に説明しています。client.Get()サーバー上でを呼び出すクライアント上にがあります。存在しない場合は、Get()を使用するようにフォールバックします。Any()
Wikiページの下部には、古いAPIから新しいAPIにサービスを手動で移植する方法が記載されています。
そして、新しいAPIを使用したいくつかの例を次に示します。