Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add support for optional parameters in function #782
The library already supports OData actions with optional parameters i.e. a client can execute an OData action with one or more optional parameters missing. For functions, we need a similar support. Presently, it seems the code flows through method
OData .Net lib 7.0.0
Define a function with optional parameter. i.e. one that does not have
OData function call is successful
"Resource not found" error.
The OData protocol doesn't support optional parameters for function invocation because it wants the service to be able to correctly route function overloads based on the URL (actions don't have overloads based on non-binding parameters for this same reason -- non-binding parameters are passed in the body).
The OData-compliant way to do this would be to define two versions of the function, one with the optional parameter and one without.
Does that not work for your scenario?
OData requires that both of the following are true:
The first rule is to support routing (since OData doesn't require the parameters to be passed in order) and the second rule was added largely for compatibility with programming languages which may want to generate corresponding strongly typed functions.
As long as we can live with these rules still being supported for all required parameters, I believe we could add optional parameters without breaking routing or language overload rules.
Would that address your requirements?
Thanks Mike.. this should address our requirements. Dynamics 365 internally does not have a mechanism to specify APIs with same name but different set of request parameters. I know of only two functions for which we added custom overloads within the OData layer. The API owners add optional parameters whenever there's a change in API to ensure that the backward compatibility is not lost (if API is called using SOAP protocol).
That should answer the last two constraints. Regarding the first one, it should be totally okay for clients to pass optional parameters in the end. Presently, whenever a change is made to the API, we have to reach all places where the API is called and add default values for the new optional parameters. This will be avoided with support for optional parameters, even under the constraints that you have mentioned.
Is this already implemented in the latest release? I'm currently having issues calling the following function signature:
public IHttpActionResult Price([FromODataUri] string key, string requiredParameter1, string requiredParameter2, string optionalParameter1 = null, string optionalParameter2 = null)`
I'm using the following builder:
FunctionConfiguration functionCustomerPrice = builder .EntitySet<Item>("Items") .EntityType .Function("Price") .Returns<Result>(); functionCustomerPrice.Parameter<string>("requiredParameter1"); functionCustomerPrice.Parameter<string>("requiredParameter2"); functionCustomerPrice.Parameter<string>("optionalParameter1").OptionalParameter = true; functionCustomerPrice.Parameter<string>("optionalParameter2").OptionalParameter = true;
referenced this issue
Jun 18, 2018
This is supported in OData Library, but not yet supported in the WebAPI OData Stack.
Unfortunately, in the current WebAPI OData stack, the "OptionalParameter" doesn't actually mean optional, it means nullable (i.e., you can provide a null value, rather than you can omit the value).
Opened OData/WebApi#1488 to track this in WebAPI OData Stack, and closing this issue.