3

试图与管理团队一起推销从传统的 ASP.Net /SOAP Web 服务迁移到 ServiceStack。

我正在努力解决一些 RPC'ish 问题。要求是我支持 SOAP（甚至是反手），希望在 REST 上销售我的服务消费者。

以一个名为“ReplaceItem”的服务为例，它基本上需要：

  1. 关闭项目编号
  2. 更换项目编号
  3. 店铺编号
  4. 一堆其他替换项目数据

我应该创建一个 ReplacementItem DTO 吗？似乎如果我有许多此类函数，我将拥有大量的 DTO，而不是大量的 RPC 方法。另外，在这种情况下，“id”是什么，我将使用什么 REST 方法？

我知道 REST/SS 为我提供了用于域级别结构（如 Items/Customers/etc）的基本 CRUD 功能，但是我如何处理 SS 中的非 CRUD 方法。

我也遇到了构成某个服务的主键的多个参数的问题。几乎所有库存表都由项目编号和商店编号构成。我宁愿不要在服务客户端上创建一些复合字符串。我该如何处理？

谢谢。

4

2 回答 2

1

ServiceStack 提倡一种类似于 SOA 的基于消息的设计，这种设计是最优的，并为远程服务提供了许多自然的好处。

我最初的想法看起来像

  1. POST {CloseItemNumber} /item/1/close
  2. 发布 {ItemNumber} /item/1?replace=true
  3. 发布 {ItemNumber} /item/1
  4. POST {ItemNumber} /item/1 即相同的 DTO/服务不同的值。

在哪里ItemNumber和CloseItemNumber是单独的请求 DTO 和服务。

设计服务 API

我更喜欢围绕“资源/名词”来构建我的服务，并将我的服务 API 设计为对它们应用操作的操作。

如果该操作需要比存储资源 DTO 更多的信息，我将创建一个带有附加元数据的单独服务。

即以下是我如何将亚马逊的“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-chatty 和基于消息的 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，则需要稍微不同地构建服务，以克服 SOAP 通过 HTTP POST 隧道传输所有操作的限制。

于 2012-08-10T05:49:13.250 回答
1

在决定从 1 个健谈的 RPC api 切换到 REST api 时，我仍然遇到的问题是，我发现自己没有几个易于维护的功能，而是有两种解决方案：

  1. 增加 DTO 和服务，使服务的内部代码变得繁琐和复杂，或者
  2. 将管理服务的所有代码放入单个路由（OnGet）中，但这样我必须解析不同的参数以“发现”已请求哪些参数（以简化而不是具有多个具有预定义参数的简单函数我现在有只有一个函数必须确定哪些参数是有意义的……但这很难维护——现在代码对我来说更复杂了）。

在解决 GetCustomerById、GetCustomersByEmails 等的建议解决方案中，对我来说，重点是，我们现在必须根据填充的参数动态构造查询，而不是简单的查询——这会使代码变得棘手且难以维护——不得不管理多个参数的可能组合 - 有些组合也不可能。

对此感到有点难过，因为我真的一点也不喜欢 WCF。混合 WCF 和 REST 似乎是复杂性的总和——对我来说是最糟糕的（定义 REST api 的复杂性 + WCF 的复杂性）。

我的感受是共享的还是我错过了什么？

于 2013-01-10T07:59:19.793 回答