Api 规则引擎的REST URI（无状态引擎）

我需要一些为规则引擎设计RESTURI的指导。后端系统中以XML文件的形式定义并存储了一组规则。这些规则分为不同的类别，并根据用户指定的类别执行一组规则。用户将一组用户选择/选项和类别作为输入传递给规则引擎。规则引擎根据用户选择/选项执行属于该类别的规则。这些是类似于进程/计算的操作，不涉及将用户状态持久化到系统中。总的来说，用户状态不在规则引擎中维护。。。即，无状态规则引擎

我正在尝试为规则引擎执行设计REST API（规则创建部分已经完成）：

该操作不创建、更新、删除任何服务端资源

根据用户选择执行规则

用户选择可能很复杂（层次结构），并且不能建模为URI参数

请您提供指导，我们正在设计一个RESTURI模式，考虑上述方面

要获取属于类别的规则，请执行以下操作：

GET /rule_category/{id}

要在规则上下文中处理用户选择（通过规则引擎执行规则），请执行以下操作：

请提供您对上述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>

{
过程数据：{
规则类别：'ruleCat1'，
用户选择：{
用户选择：[
{
项目：“us1”
},
{
项目：“us2”
},
{
项目：“us3”，
客户选择：{
值：'cs1'
}
}
]
}
}
}

---

REST不是远程过程调用（RPC）。剩下的就是资源

如果您希望有一个处理计算的RESTful API，请将计算建模为资源

创建一个新的计算资源 请求

POST /computations
Content-Type: application/json

{
  // the selected rules etc.
}

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

响应

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

其中，

748A9FC0-B74E-11E4-8822-4D7FDD9DA696

是服务器生成的此计算的ID

获取计算的状态 请求

POST /computations
Content-Type: application/json

{
  // the selected rules etc.
}

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
  }
}

---

在这种情况下，你唯一的选择就是发帖

请注意，REST具有约束，例如统一接口约束，其中包括HATEOAS。所以你必须向你的客户发送链接，他们可以跟踪。在这种情况下，您将很难解释（机器）客户端如何组装请求主体。克服这一问题的一种可能方法是定义特定于应用程序的请求媒体类型

---

所以用REST解决这个问题是可能的，但我认为在这种情况下，您将比使用RPC工作得更多。我同意Lutz的观点，如果服务器上没有保存状态的其他资源，则不应通过规则引擎使用REST。

请包含您要发布的JSON正文示例。这样的

POST

请求将创建某种“进程”资源。

{process:{rulecategory:'ruleCat1'，userselection:{userselection:[{item:'us1'}，{item:'us2'}，{item:'us3'，customselection:{value:'cs1'}}]}

1）这不是有效的JSON。2）您可以在那里添加JSON。@LutzHorn已完成。您能否提供一些建议，说明我们如何对不打算在服务器上发布/放置/删除资源的URI进行建模。这些类似于计算API。引擎计算结果并返回结果。不会保留任何数据。谢谢您的帮助谢谢您的回复但这需要：（1）一个额外的调用（2）需要保持用户状态（即选择）在服务器端。我们的设计原则是将其维护为无状态系统，因为它在可伸缩性和性能方面具有优势。因此，我想知道我们是否可以在不需要创建资源的情况下对REST URI进行建模。对于重载POST/PUT HHTP方法来执行计算操作，您有何看法？您有何建议t是RPC，不是REST。REST是关于资源的。谢谢。感谢您的帮助谢谢您的帮助。。。