面向任务的用户界面和 Rest 应用程序服务器 API
我正在设计一个系统，其中用户界面将使用面向任务的 UI 和 CRUD UI 的混合来构建。这样我们希望能够为不同的用户角色提供最佳的用户体验。
客户端应用程序使用 REST/JSON 与应用程序服务器进行通信。
对于 CRUD 部分，REST API 部分大多是直接的。但是在我们的应用程序中为面向任务的操作设计 API 有点困难。
如何设计一个 REST API 来区分资源上的两种不同操作，而这两种操作实际上都只是更新数据？
举个例子 - 用户可以出于以下原因更改某人的地址：
- 地址包含错误，例如街道名称拼写错误 错误的。
- 该人已搬到不同的地址 这
两种原因都会导致相同的最终情况；数据已更改。但在 REST API 中应该存在某种差异，以便能够做出不同的反应。
I am designing a system where the user interface will be constructed using a mixture of task oriented UI and CRUD UI. This way we want to be able to have an optimal user experience for different user roles.
The client application uses REST/JSON to communicate with the application server.
For the CRUD part the REST API part is mostly straight foreward. But designing the API for the task oriented actions in our application is a little bit more difficult.
How would one go about designing a REST API that makes a distinction between two different actions on a resource that both actually just update the data?
As an example - The user can change a person's address for the following reasons:
- The address contains a fault, e.g. the street's name is spelled
wrong. - The person has moved to a different address
Both reasons result in the same end situation; the data has changed. But in the REST API there should somehow be a difference to be able to react differently.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一般来说，REST 资源是一个名词。然而，资源作为流程或流程步骤也是合法的。因此，对于您给出的示例，我可能会这样做：
在后一种情况下，HTTP 正文可能包含其他信息，例如“有效日期”。此外，从上述 POST 返回的内容位置标头可能包含显示旧地址、新地址以及转换发生时间的资源的 URI。
因此，changeOfAddress 名义上是一个“过程”，但实际上它本身就是一个名词；从模特视角来看，它是一等公民。
Generally a REST resource will be a noun. However, it is also legitimate for the resource to be a process or process step. Thus for the example you've given, I might do this:
In the latter case, the HTTP body would presumably contain additional information such as "effective date". Also, the content-location header returned from the above POST likely would contain the URI to resource that shows the old address, the new address, and when the transition occurred.
Thus the changeOfAddress is nominally a "process" but it is practically a noun unto itself; from a modelling POV, it is a first-class citizen.
如果您需要不同的“更新”方法，那么我只需在名称中包含一些描述性内容（例如：
/Address/UpdateStreetName）。您可以包含“/Update”方法，但要针对可能开始看起来有点模糊的更具体的名称。另外，API 是否以数据或潜在用户场景为中心？就我个人而言，我会根据数据构建我的 API - 但要确保它涵盖所有可能的场景。例如，单独更新街道名称可能有意义（因为它可能会拼写错误），但这是否自动意味着您希望单独提供每个其他字段的更新能力？也许，也许不是。
可以肯定的是，一个好的 API 将允许用户有效地工作并覆盖所有/大多数场景 (%80 >)，而不会产生不必要的麻烦，但是通过采用以数据为中心的方法作为粗略指南，您将不太可能不必要地重复。例如，更改地址会有多种原因（并非所有原因在设计时都已知），移动到不同的地址只是其中之一 - 但总体影响是相同的（因为正在更改相同的数据）。
If you need to have different "update" methods then I would simply include something descriptive in the name (e.g:
/Address/UpdateStreetName). You could include a "/Update" method but against the more specific names that might start to look a bit ambiguous.Also, is the API centered around the data or potential user scenarios? Personally, I would build my API based on the data - but making sure that it covered all likely scenarios. For example, updating the street name individually might make sense (on the basis that it can be mis-spelt) but does that automatically mean that you'd want to offer update ability on every other field individually? Maybe, maybe not.
To be sure - a good API will allow users to work effectively and cover all / most scenarios (%80 >) without un-due hassle, but by taking a data-centric approach as a rough guide you'll be less likely to duplicate unnecessarily. For example, there will be multiple reasons to change an address (not all might be known at design time), moving to a different address is only one - but the overall affect would be the same (as the same data is being changed).
我一直在开发一个小实用程序，它允许您将 CQRS 命令发布到 RESTful url。 CQRS 非常适合面向任务的 UI。但对于一些项目来说，在管理场景中您可能想要管理整个对象（例如ManagingAddress）。只是不要忘记，通过从所有包含的管理 UI 更改属性，您可能会无意中丢失一些由更细粒度的命令捕获的逻辑 - 在您的情况下为 ChangeAddress）。
在这种情况下，很明显您正在执行两个单独的命令（一个命令比另一个命令更细粒度）。是否将它们表示为两个单独的 URL 由您决定，但请注意，任何其他对象可能需要类似类型的 CRUD 接口和 REST URL。但无论哪种情况，我都只是将更精细的命令烘焙到更复杂的命令中（因此，在更广泛的无所不包的命令中会拾取更精细的细节）。
I've been working on a little utility that allows you to post CQRS commands to RESTful url. CQRS is a good match for task oriented UI. But for a few projects it is understood in management scenarios you may want to manage an entire object (eg. ManagingAddress). Just don't forget that by changing a property from all encompassing management UI you could be inadvertently be missing some logic that is capture by a more granular command - in your case ChangingAddress).
In cases like this it is apparent that you are performing two separate commands (one is just more granular than the other). Whether you represent these as two separate URLs is up to you, with the reminder that any addtional objects may require a similar type of CRUD interface and REST URL. But in either case I simply just bake the more granular command into my more complex command (so granular specifics are picked up in your broader all encompassing command).