在我整理的 API 中，我对一组实体执行Action。我遇到的问题是如何允许操作根据客户的偏好和支持的方法而变化。
一些动作类型将需要客户端提供额外的选项：例如，其中一个动作将导致发送一封电子邮件，因此客户端需要提供正文、收件人等。服务器可能比客户端知道更多的动作类型。例如，可以添加新的发送方法，但旧客户端不知道如何为其设置选项。除此之外，还有一些操作类型不需要客户端提供任何选项，因此所有客户端都可以在服务器启用后立即使用它。
除了根据客户端/服务器支持的动作类型改变动作类型外，选择的实体也会产生影响——某些实体对某些动作类型无效。
在协商结束时，客户端（最终是最终用户）可以自由选择适用于这些实体的任何“无选项”动作类型，或适用于这些实体的任何“需要选项”动作类型, 客户端和服务器都支持。
通过将状态字段设置为committed或类似来触发操作。
到目前为止，我的想法是提供一个通用DoAction资源，其中包含实体的子集合。此资源的属性允许您指定“ActionType”。然后是另一个子资源ActionOptions，您可以在其中为您正在使用的特定类型设置选项，或者将其留空以用于“无选项”类型。
我遇到的问题是决定这是否是最好的方法，或者涉及内容类型的东西是否会更好，以及如何为客户端协商可用操作类型的列表，包括客户端的无选项类型即使它没有明确知道它也可以支持。