Swagger: Custom action in REST API

Question

In our REST API project we are finding it a little difficult document a REST API that supports multiple custom actions.

Multiple actions such as VALIDATE, PROCESS etc can be performed on this resource. The data is not persisted in back-end, instead a rule engine (in the back-end) would perform these actions on the resource and return the result.

REST URI: PUT http://<hostnam>:<port>/<context-root>/rest/configuration

Body:

{
     "action": "VALIDATE",
     "commonAttribute": "",
     "validateAttribute": ""
}

or

{
     "action": "PROCESS",
     "commonAttribute": "",
     "processAttribute": ""
}

For VALIDATE action a common attribute and a validate specific attribute are provided (validateAttribute). Similar is the case with PROCESS action.

Configuration POJO was created to represent the input in the following manner:

public class Configuration {
    // will be modeled as enum
    private String action;

    private String commonAttribute;
    private String validateAttribute;
    private String processAttribute;

    // getters and setters
}

Since these two actions are implemented in a single REST URI, the swagger documentation becomes slightly complicated. Under this URI, the model schema for the body of the request would contain both validateAttribute and processAttribute as show below:

{
    "action": "string",
    "commonAttribute": "string",
    "validateAttribute": "string",
    "processAttribute": "string"
}

The presence of both the attributes create some sort of confusion for the users, even-though the granular details such as which-attribute-for-which-action can be covered in verbal documentation (within swagger).

Note 1: Based on REST design guidelines, these actions were not included in the REST URI path. Note 2: PUT action was chosen over POST as our operations are idempotent in nature.

I am looking for guidance in terms of representing these actions and its attributes in a precise and concise manner in swagger doc. Is there a better way of designing these APIs or representing them in swagger.