rest - 将 RESTful 资源映射到现有域的最佳实践

Question

我们将创建一些 RESTful 服务，这些服务本质上将成为一些老式的基于 SOAP 的 Web 服务的传递。 SOAP 服务更加通用，将在我们整个组织中使用(至少这是计划)。 RESTful 服务是为特定客户量身定制的。这个决定已经做出，不幸的是我无法控制改变......

我们正在努力寻找如何以合理的方式构建我们的 RESTful 资源，遵循 REST 最佳实践，并在调用这些 SOAP 服务时不会给我们带来太多痛苦。

我们在后端服务的粒度级别上有一些自由，但普遍的共识是:保持它们的粗粒度，不要根据特定客户的需求定制它们。

这导致了一些有趣的问题。例如，如何处理父级的子资源。我们一直在使用的典型示例是:具有子地址的客户。

我们有一个后端 SOAP 服务，它将客户作为一个整体进行更新。但是，REST 服务客户端可能只需要更新账单地址。我们如何最好地处理子资源的后续更新？

我们应该在“父”级别(客户)进行更新，还是公开一个更细粒度的 REST 操作，将地址视为资源并以这种方式更新？后者似乎是正确的 RESTful 方式。但是，如果我们这样做，我们实际上只会为一个更新调用粗粒度的后端服务。似乎没有意义，因为这是一个相当重量级的电话。

我们也在努力解决如何将 RESTful 资源与我们的后端域模型相关联。我们可能将 RESTful 资源视为单个实体，但在我们后端的域中，它可能是许多不同的实体。我们现在有一个相对简单的 DB 表来处理这个问题，但我不相信它会随着我们将越来越多的资源映射到域对象而扩展。

这些只是我们正在做的事情的几个例子......我想知道是否有人遇到过类似的问题并且有任何建议或者可以向我指出一些可能有一些最佳实践的文章.

看起来这不是一个不寻常的问题，并且随着越来越多的应用程序使用 RESTful 架构而变得更加相关，但我似乎找不到任何其他信息。

非常感谢!

Answer 1

我发现我建模的大多数域很容易映射到 REST。最重要的事情是进入正确的心态。 REST 将域建模为一组资源，其中 SOAP 倾向于强调一组操作。另一种看待这个问题的方式是 REST 关注状态，而 SOAP 关注状态转换。更简单的是，您可以将 REST 视为名词，而将 SOAP 视为动词。我知道这不是一个完美的类比，但它对我很有用。

当您进入这种思维状态时，映射对您来说几乎是自动的。让我们看看您的客户地址交互。

我不认为仅仅为了更新地址而更新整个客户是不合适的，但不熟悉您的域，也许是。如果您想专门与地址交互，只需创建一个子资源(或嵌套资源)。您最终会得到以下 url 和动词的映射:

GET /customer/72/address    # return the address of customer with id 72
PUT /customer/72/address    # update the address of customer with id 72

在这种特殊情况下，映射删除、创建或列出操作可能没有意义。

如果您的客户有一些实体的集合，比如说小部件，您可以像这样映射交互:

GET     /customer/72/widgets        # return the widgets of customer with id 72
POST    /customer/72/widgets        # create a new widget for customer with id 72
GET     /customer/72/widgets/158    # return widget with id 158 of customer 72
PUT     /customer/72/widgets/158    # update widget with id 158 of customer 72
DELETE  /customer/72/widgets/158    # delete widget with id 158 of customer 72

只要有正确的心态，并记住映射不会是一对一的，你会没事的。