规则引擎(无状态引擎)的 REST URI

REST URIs for a Rule Engine (stateless engine)

我需要一些指导来为规则引擎设计 REST URI。有一组规则以 XML 文件的形式定义并存储在后端系统中。这些规则被分为不同的类别,并根据用户指定的类别执行一组规则。用户将一组用户 selections/options 和类别作为输入传递给规则引擎。规则引擎针对用户selections/options执行属于类别的规则。这些是 process/compute 之类的操作,不涉及将用户状态持久化到系统中。总的来说,规则引擎中不维护用户状态...即无状态规则引擎。

我正在尝试为规则引擎执行设计 REST API(规则创建部分已经处理):

  1. 该操作不会创建、更新、删除任何服务器端资源。
  2. 根据用户选择执行规则。
  3. 用户选择可能很复杂(层次结构)并且不能建模为 URI 参数。

请求您的指导正在考虑上述方面设计 REST URI 模式。

获取属于类别的规则:

GET /rule_category/{id}

在规则上下文中处理用户选择(由规则引擎执行规则):

POST /rule_engine
BODY to contain a JSON structure with rule category & user selections

请就上述 URI 设计和上述用例的任何其他可能的 URI 提供您的建议。 PUT/POST 是否应该用于规则执行 URI?

编辑 1:添加封装规则类别和用户选择信息的示例 JSON/XML 结构:

{
    processdata:{
        rulecategory:'ruleCat1',
        userselections:{
            userselection:[
                {
                    item:'us1'
                },
                {
                    item:'us2'
                },
                {
                    item:'us3',
                    customselection:{
                        value:'cs1'
                    }
                }
            ]
        }
    }
}

<ProcessData RuleCategory="ruleCat1">
<UserSelections>
    <UserSelection Item="us1"/>
    <UserSelection Item="us2"/>
    <UserSelection Item="us3">
        <CustomSelection Value="cs1"/>
    </UserSelection>
</UserSelections>

REST 不是远程过程调用 (RPC)。 REST 是关于资源的。

如果你想要一个 RESTful API 来处理计算,将计算建模为资源。

创建新的计算资源

请求

POST /computations
Content-Type: application/json

{
  // the selected rules etc.
}

回应

201 Created
Location: /computations/748A9FC0-B74E-11E4-8822-4D7FDD9DA696

其中 748A9FC0-B74E-11E4-8822-4D7FDD9DA696 是服务器生成的此计算的 ID。

获取计算状态

请求

GET /computations/748A9FC0-B74E-11E4-8822-4D7FDD9DA696

响应:仍在计算

200 OK
Content-Type: application/json

{
  "id": "748A9FC0-B74E-11E4-8822-4D7FDD9DA696",
  "data": { ... },
  "state": "computing"
}

响应:完成

200 OK
Content-Type: application/json

{
  "id": "748A9FC0-B74E-11E4-8822-4D7FDD9DA696",
  "data": { ... },
  "state": "finished",
  "result": {
    // details about the result
  }
}

在这种情况下,您唯一的选择是 POST。

请注意 REST 有限制,例如统一接口约束,其中包括 HATEOAS。因此,您必须将链接发送给您的客户,他们可以关注这些链接。在这种情况下,您将很难向(机器)客户端解释如何 assemble 您的请求正文。解决这个问题的一种可能方法是定义您的应用程序特定请求媒体类型。

因此可以使用 REST 解决此问题,但我认为您在这种情况下的工作量要比 RPC 多得多。我同意 Lutz 的观点,如果你没有其他资源,你的规则引擎不应该使用 REST,这些资源的状态保存在服务器上。