面向任务的用户界面和Rest应用服务器API

Question

我正在设计一个系统，其中将使用面向任务的UI和CRUD UI的混合构建用户界面。这样，我们希望能够为不同的用户角色提供最佳的用户体验。

客户端应用程序使用REST / JSON与应用程序服务器通信。

对于CRUD部分，REST API部分大部分都是直接的。但是，在我们的应用程序中为面向任务的操作设计API会有点困难。

如何设计一个REST API来区分资源上的两个不同的操作，这两个操作实际上只是更新数据？

作为示例 - 用户可以更改某人的地址，原因如下：

1. 地址包含错误，例如这条街的名字是拼写的 错。
2. 此人已移至其他地址

这两个原因导致同样的结局;数据已经改变。但是在REST API中，应该能够以不同的方式做出不同的反应。

Answer 1

如果您需要使用不同的“更新”方法，那么我只需在名称中包含一些描述性内容（例如：/Address/UpdateStreetName）。您可以包含一个“/ Update”方法，但针对可能开始看起来有点模棱两可的更具体的名称。

此外，API是围绕数据还是潜在的用户场景？就个人而言，我会根据数据构建我的API - 但要确保它涵盖所有可能的场景。例如，单独更新街道名称可能是有意义的（基于它可能拼写错误），但这是否自动意味着您希望单独为每个其他字段提供更新功能？也许，也许不是。

可以肯定 - 一个好的API将允许用户有效地工作并覆盖所有/大多数情况（％80＆gt;）而不会有任何麻烦，但通过采用以数据为中心的方法作为粗略指导，您将成为不太可能不必要地复制。例如，更改地址的原因有多种（并非所有地址都可能在设计时都知道），移动到不同的地址只有一个 - 但总体影响是相同的（因为相同的数据正在被更改）。

Answer 2

我一直在研究一个小实用程序，它允许您将CQRS命令发布到RESTful URL。 CQRS非常适合面向任务的UI。但是对于一些项目，在管理场景中可以理解您可能想要管理整个对象（例如ManagingAddress）。只是不要忘记，通过从所有包含的管理UI更改属性，您可能会无意中遗漏一些由更细粒度的命令捕获的逻辑 - 在您的情况下更改AddressAddress）。

在这种情况下，显然您正在执行两个单独的命令（一个比另一个更精细）。您是否将这两个URL表示为由您自己决定，并提醒您任何addtional对象可能需要类似类型的CRUD接口和REST URL。但在任何一种情况下，我只是将更细粒度的命令烘焙到更复杂的命令中（因此，在更广泛的所有包含命令中选择了细粒度的特定信息）。

Answer 3

通常，REST资源将是名词。但是，将资源作为流程或流程步骤也是合法的。因此，对于您给出的示例，我可能会这样做：

• 更正地址中的拼写错误：

  

PUT / resource / customer / 123 / address

• 客户搬家，执行地址变更：

  

POST / resource / customer / 123 / changeOfAddress

在后一种情况下，HTTP主体可能会包含其他信息，例如＆＃34;生效日期＆＃34;。此外，从上面的POST返回的内容位置标头可能包含显示旧地址，新地址以及转换发生时间的资源的URI。

因此，changeOfAddress名义上是一个＆＃34;进程＆＃34;但实际上它本身就是一个名词;从模特POV来看，它是一流的公民。