3

管理チームと共に、従来の ASP.Net /SOAP Web サービスから ServiceStack への移行を売り込もうとしています。

I am struggling with a some RPC'ish issues. Requirement is that I support SOAP (even backhandedly) in the hope of selling my service consumers on REST.

Take for example a service called "ReplaceItem" which basically requires:

  1. Close out item number
  2. Replacement item number
  3. Store Number
  4. Bunch of other replacement item data

Should I create a ReplacementItem DTO? It seems to be if I have a number of these type of functions I am just going to have tons of DTOs instead of tons of RPC methods. Plus what is the "id" in this case and what REST method would I be using?

I get that REST/SS gives me basic CRUD functionality for domain level structures like Items/Customers/etc, but how do I handle non-CRUD methods in SS.

特定のサービスの主キーを構成する複数のパラメータにも問題があります。ほとんどすべての在庫テーブルは、アイテム番号と店舗番号で構成されています。サービスクライアントでの複合文字列の作成をダンプしたくありません。どうすればこれを処理できますか?

ありがとう。

4

2 に答える 2

1

ServiceStack は、SOA に似たメッセージ ベースの設計を促進します。これは最適であり、リモート サービスに多くの自然なメリットをもたらします。

私の最初の考えは次のようになります

  1. POST {CloseItemNumber} /item/1/close
  2. POST {アイテム番号} /item/1?replace=true
  3. POST {アイテム番号} /アイテム/1
  4. POST {ItemNumber} /item/1 つまり、同じ DTO/サービスの異なる値。

ここItemNumberで、 とCloseItemNumberは別のものです。 DTO とサービスを要求します。

サービス API の設計

「リソース/名詞」を中心にサービスを構築し、サービス API をそれらに操作を適用するアクションとして設計することを好みます。

操作でリソース DTO を保存するよりも多くの情報が必要な場合は、追加のメタデータを使用して別のサービスを作成します。

つまり、Amazon の「RPC」サービスをより REST-ful なものに変換する方法は次のとおりです。

https://ec2.amazonaws.com/?Action=AttachVolume
&VolumeId=vol-4d826724
&InstanceId=i-6058a509
&Device=/dev/sdh
&AUTHPARAMS

私がそれをどのように書くのが好きかについて：

POST https://ec2.amazonaws.com/volumes/vol-4d826724/attach 
FormData: InstanceId=i-6058a509&Device=/dev/sdh&AUTHPARAMS

明示的なAttachVolume Request DTOを引き続き使用します。

WCF RPC と ServiceStack の粗粒度メッセージ ベースのアプローチの違いを紹介するために使用する別の例は、https ://gist.github.com/1386381 にあります。

RPC チャット API とメッセージ ベース API の違い:

これは、WCF が推奨する典型的な 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);
}

これは、ServiceStack で推奨されている同等のメッセージ ベースの API です。

public class Customers {
   int[] Ids;
   string[] UserNames;
   string[] Emails;
}

public class CustomersResponse {
   Customer[] Results;
}

注: 同じサービスで SOAP と REST ベースの API の両方をサポートする場合は、HTTP POST を介してすべての操作をトンネリングするという SOAP の制限を克服するために、サービスを少し異なる構造にする必要があります。

于 2012-08-10T05:49:13.250 に答える
1

1 つのおしゃべりな RPC API から REST API に切り替えることを決定したときにまだ抱えている問題は、いくつかの機能を簡単に維持できるのではなく、次の 2 つのソリューションのいずれかを使用していることです。

  1. おしゃべりで複雑なサービスの内部コードを作成するDTOとサービスを増やすか、
  2. サービスを管理するすべてのコードを単一のルート (OnGet) に入れますが、この方法では、さまざまなパラメーターを解析して、どのパラメーターが要求されたかを「発見」する必要があります (事前定義されたパラメーターを持つ複数の単純な関数を使用する代わりに単純化するため)どのパラメーターが意味を持つかを判断する必要がある関数は1つだけです...しかし、それを維持するのは非常に困難です-コードは今私にとってより複雑です)。

GetCustomerById、GetCustomersByEmails などを解決するために提案されたソリューションでは、単純なクエリを使用する代わりに、入力されたパラメーターに基づいてクエリを動的に構築する必要があるということです。複数のパラメータの可能な組み合わせを管理します - 一部の組み合わせは不可能です。

私は本当にWCFがまったく好きではないので、それについて少し悲しい気持ちです。WCF と REST を混在させることは、複雑さの合計のように思えます。私にとっては最悪です (REST API の定義の複雑さ + WCF の複雑さ)。

私の気持ちは共有されていますか、それとも私は何かを逃しましたか?

于 2013-01-10T07:59:19.793 に答える