试图向管理团队推销从传统 ASP.Net/SOAP 网络服务向 ServiceStack 的迁移。
我正在努力解决一些 RPC'ish 问题。要求是我支持 SOAP(甚至是反手),希望在 REST 上销售我的服务消费者。
以名为“ReplaceItem”的服务为例,它基本上需要:
- 关闭项目编号
- 替换品编号
- 店铺编号
- 一堆其他替换项数据
我应该创建一个 ReplacementItem DTO 吗?似乎如果我拥有大量此类功能,我将拥有大量的 DTO 而不是大量的 RPC 方法。另外,在这种情况下,“id”是什么以及我将使用什么 REST 方法?
我知道 REST/SS 为领域级结构(如 Items/Customers/等)提供了基本的 CRUD 功能,但我如何处理 SS 中的非 CRUD 方法。
我还遇到了多个参数组成某个服务的主键的问题。几乎所有的 Inventory 表都是由 Item Number 和 Store Number 构成的。我宁愿不在服务客户端上转储某些复合字符串的创建。我该如何处理?
谢谢。
最佳答案
ServiceStack 提倡一种类似于 SOA 的基于消息的设计,这种设计是最优的并且 provides many natural benefits for remote services .
我最初的想法是这样的
- POST {CloseItemNumber}/item/1/close
- POST {ItemNumber}/item/1?replace=true
- 发布 {ItemNumber}/item/1
- POST {ItemNumber}/item/1 即相同的 DTO/服务不同的值。
ItemNumber
和 CloseItemNumber
是单独的请求 DTO 和服务。
设计服务 API
我更喜欢围绕“资源/名词”构建我的服务,并将我的服务 API 设计为将操作应用于它们的操作。
如果操作需要比存储 Resource 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 请求 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,您需要 structure your services slightly differently克服 SOAP 通过 HTTP POST 隧道化所有操作的限制。
关于servicestack - 服务堆栈将 RPC 迁移到 REST 问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11890915/