Add a parameter classifier to the Function definition scheme

[ricardozanini]

What would you like to be added:
A way to classify the parameter in the function definition (optional) so implementations could have a hint of how to handle the parameter when executing a given function.

For example a given operation state:

 "functions": [
        {
            "name": "userAuthServiceCall",
            "resource": "http://authservice.com",
            "type": "rest",
            "parameters": [
                {"name": "user", "classifier": "querystring"},
                {"name": "token", "classifier": "header"}
            ],
            "metadata": {
                "method": "GET"
            }
        }
]
(...)

Why is this needed:
With the classifier, implementations would know how to handle these parameters on a REST call scenario for instance.

[wanghq]

@ricardozanini are you aware of any standard way to build common (HTTP) request and make the call so any APIs can be supported? e.g. Postman has a pretty comprehensive doc about how to build request. Also I think authorizing the request is also important. It would be nice if the spec could leverage any existing/open/popular way to define function.

[tsurdilo]

I think that we are ok in this regard. Function definitions can be used to enforce openapi / swagger, it really depends on the impl of course but I will add examples for rest invokes that look like :

"functions": [
{
"name": "PetStoreFunctions",
"resource": "https://petstore.swagger.io/v2/swagger.json"
}
]

"resource" does not need to be an end-point url, especially when using/enforcing openapi.
In this example a function definition is not even one single function, it is a reference to an openapi description
And states actions can pass in for example the "operationId" parameter which then can invoke the associated function in the swagger definition ...so just think instead of having 50 different function definitions for each, you just do 1 :)

"type" may be enforced by some implementations to give them more insight of what the function represents, but since it is just a string it is not portable. I am thinking we should at some point remove it, to enforce portability honestly, but we need to think about that.

[tsurdilo]

We will require use openapi spec for all function definitions. More to come on this soon :)

[ricardozanini]

Closing this one since #145 will solve this requirement