REST URIs for a Rule Engine (stateless engine) [closed] - api

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I need some guidance for designing REST URIs for a rule engine. There are a set of rules defined and stored in the back-end system in the form of XML files. These rules are grouped into various categories and a set of rules get executed based on the category specified by the user. The user passes a set of user selections/options and category as input to the rule engine. The rule engine executes the rules belonging to the category against the user selections/options. These are process/compute like operations which doesn't involve persistence of user state into the system. On a whole, the user state is not maintained in the rule engine... ie., a stateless rule engine.
I am trying to design REST APIs for rule engine execution (rule creation part is already taken care of):
The operation doesn't Create, Update, Delete any serve side resources.
The rules are executed against the user selections.
User selections can be complex (hierarchical structure) and it can't modeled as URI params.
Request your guidance is designing a REST URI pattern considering the above mentioned aspects.
To get a rules belonging to a category:
GET /rule_category/{id}
To process user selections in the context of rules (rule execution by rule engine):
POST /rule_engine
BODY to contain a JSON structure with rule category & user selections
Please provide your suggestions on the above URI design and any other possible URIs for the above mentioned use case. Should PUT/POST be used for rule execution URI?
EDIT 1: Adding the sample JSON/XML structure that encapsulates rule category and user selection info:
{
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>

Answer 1

REST is not Remote Procedure Call (RPC). REST is about Resources.
If you want to have a RESTful API that handles computations, model computations as resources.
Create a new computation resource
Request
POST /computations
Content-Type: application/json
{
// the selected rules etc.
}
Response
201 Created
Location: /computations/748A9FC0-B74E-11E4-8822-4D7FDD9DA696
where 748A9FC0-B74E-11E4-8822-4D7FDD9DA696 is the ID of this computation generated by the server.
Get the state of the computation
Request
GET /computations/748A9FC0-B74E-11E4-8822-4D7FDD9DA696
Response: still computing
200 OK
Content-Type: application/json
{
"id": "748A9FC0-B74E-11E4-8822-4D7FDD9DA696",
"data": { ... },
"state": "computing"
}
Response: finished
200 OK
Content-Type: application/json
{
"id": "748A9FC0-B74E-11E4-8822-4D7FDD9DA696",
"data": { ... },
"state": "finished",
"result": {
// details about the result
}
}

Answer 2

Your only options is POST in this case.
Be aware that REST has constraints e.g. uniform interface constraint, which includes HATEOAS. So you have to send links to your clients, which they can follow. In this case you will have hard time to explain the (machine) clients how to assemble the body of your request. A possible way to overcome this, is defining your application specific request media type.
So it is possible to solve this with REST, but I think you will work in this case much more than you would by an RPC. I agree with Lutz, you should not use REST by your Rule Engine if you don't have other resources which state are kept on the server.