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

【问题标题】：Task oriented user interface and Rest application server API面向任务的用户界面和 Rest 应用服务器 API
【发布时间】：2015-11-13 09:50:13
【问题描述】：

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

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

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

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

例如 - 用户可以出于以下原因更改某人的地址：

地址包含错误，例如街道名称是拼写的错了。
此人已搬到其他地址

这两个原因导致相同的最终情况；数据发生了变化。但在 REST API 中，应该有某种差异才能做出不同的反应。

【问题讨论】：

标签： api architecture task

【解决方案1】：

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

更正地址中的错字：

PUT /resource/customer/123/address

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

POST /resource/customer/123/changeOfAddress

在后一种情况下，HTTP 正文可能包含附加信息，例如“生效日期”。此外，从上述 POST 返回的内容位置标头可能包含指向资源的 URI，该 URI 显示了旧地址、新地址以及转换发生的时间。

因此，changeOfAddress 名义上是一个“过程”，但实际上它本身就是一个名词；从造型 POV 看，它是一等公民。

【讨论】：

非常好的答案！

【解决方案2】：

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

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

可以肯定的是 - 一个好的 API 将允许用户有效地工作并涵盖所有/大多数场景 (%80 >) 而没有不必要的麻烦，但是通过以数据为中心的方法作为粗略的指导，你会更少可能会不必要地重复。例如，更改地址将有多种原因（在设计时可能并不知道所有原因），移动到不同的地址只是一个 - 但总体影响是相同的（因为正在更改相同的数据）。

【讨论】：

应用程序的很大一部分是基于 CRUD 操作的，因此选择以数据为中心的 REST 风格的 API 对我来说似乎是一个自然的选择。但这与 RPC 风格的 API 相比也有一些缺点。例如：/Address 和 /Address/UpdateStreetName 都以相同的资源为目标，但现在使用不同的 URI。这不只是以不同的格式进行 RPC 风格的调用吗？整体效果是一样的；地址得到更新。但是当这个人搬家时，我们可能想给这个人寄一张明信片到新地址，我们不想这样做，因为我们只是修正了一个错字。
好吧，对我来说 /Address/Update 和 /Address/UpdateStreetName 是不同的：一个意味着可以编辑整个地址，另一个更精确（但仍然限于地址）。对于更具体的情况，您可以采用基于场景的方法，例如： /ChangeOfAddress 作为地址更改可能不仅仅影响地址；所以你可以用它作为其他调用的门面，比如 /PhoneNumber/Update （但我可能会偏离这里的路径）。

【解决方案3】：

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

在这种情况下，很明显您正在执行两个单独的命令（一个比另一个更细化）。是否将它们表示为两个单独的 URL 取决于您，并提醒您任何其他对象可能需要类似类型的 CRUD 接口和 REST URL。但在任何一种情况下，我都只是将更精细的命令融入到更复杂的命令中（因此，更精细的细节会在您更广泛的无所不包的命令中得到体现）。

【讨论】：