Search code examples
apiresturistateless

REST URIs for a Rule Engine (stateless engine)


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):

  1. The operation doesn't Create, Update, Delete any serve side resources.
  2. The rules are executed against the user selections.
  3. 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>


Solution

  • 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.