rest - ServiceStack:使用单一路由在一个资源上执行多个业务流程

Question

我的团队正在为处理物理 Assets 跟踪的现有企业应用程序设计 REST API。

我们的域模型非常复杂，我们在设计路由时遇到了阻塞问题。

理想情况下，我们希望每个资源都支持多个业务流程。但是，如果不扩展资源的 URL 以帮助 ServiceStack 的路由引擎确定要使用哪个 DTO，我们就无法找到一种方法来做到这一点。

这是一个例子。我们保留了涉及小部件的交易的详细历史记录，并且用户可以对我们代表不同类型交易的小部件执行多种类型的操作。例如 widget可以检查，也可以清洗。两者都是针对 /api/widget/{id} 的操作，但第一个导致检查事务，第二个导致维护事务。我们真的很想创建使用相同路由的不同 DTO，/api/widget/{id} ，并根据请求正文选择正确的 DTO。

这似乎是不可能的。相反，看起来我们需要创建两个端点:/api/widgets/{id}/inspect和 /api/widgets/{id}/clean ，或类似的东西。

这感觉不是很 RESTful，因为它离 /api/cleanWidget 不远.它更像是一种方法调用，而不是对资源的更新。

我们讨论过的另一个选项是创建单个 /api/transactions端点，因为对 API 的大多数请求都会导致创建事务。然而，这将导致一个单一的、单一的端点，并且用户必须弄清楚他们需要为给定类型的请求填充几十个可能的数据属性中的哪一个。它也与我们的用户将为其编程的用例相去甚远。他们更关心与他们交互的物理实体，而不是我们的幕后实现。

两个问题:

我们是否错误地考虑了这一点？有没有更好的方法来以 RESTful 方式对此进行建模？

如果我们的想法是正确的，那么在确定满足请求时使用哪个DTO和服务方法时，有没有一个好的方法可以使用ServiceStack来考虑请求体？

Answer 1

怎么样/api/widgets/{id}/inspection ?如果你 PUT 它你可以开始检查，如果你得到它你可以得到检查状态。

如果您同时运行更多检查(以及您提到的事务)，您可以设想一个模式，您可以在其中 POST 到 /api/widgets/{id}/inspections为了在 /api/widgets/{id}/inspections/{id}/ 创建一个新的检查.在这里你可以 GET 查看状态，DELETE 取消等等。

如果您想根据消息正文确定 URL，一种想法是使用 /api/widgets/{id}/transactions资源，您可以在其中发布消息。此资源可以解析正文并返回 201 并引用 /api/widgets/{id}/inspections/{id}/如果 body 要求检查，或到 /api/widgets/{id}/cleanings/{id}/如果 body 要求清洁。

这只是一些想法。顺便说一句，你可能想看看 RESTify DayTrader一些灵感。