A developer is defining a custom API named contoso_GetOrderStatus that callers invoke with the ID of an order and that returns the order's status as text. The order ID must always be supplied. How should the request parameter and response property be defined?
Select an answer to reveal the explanation.
Short Explanation
Inputs go in request parameters, outputs go in response properties; think of it as your in tray and your out tray. The order ID comes in as a required Guid and the status goes out as a String. The trap is trying to return a value through a request parameter.
Full Explanation
A custom API definition is made of the CustomAPI record plus CustomAPIRequestParameter records for inputs and CustomAPIResponseProperty records for outputs, each with a unique name and a type from a fixed list that includes Guid, String, EntityReference and others. The order ID is an input that must always be supplied, so it is a request parameter of type Guid with IsOptional set to false. The status is an output, so it is a response property of type String; the plug-in that implements the main operation sets it in OutputParameters. A second request parameter cannot return data to the caller, because request parameters are inputs only. Making the order ID optional contradicts the requirement that it always be supplied, and returning an Entity response would hand back a full row when the contract specifies status text. Placing the order ID in a response property and the status in a request parameter reverses the direction of data flow, and response properties have no required setting. Exam caveat: the type and IsOptional values cannot be changed after the parameter is saved, so decide them carefully; an EntityReference parameter is an alternative when the caller should pass a table reference. Operational check: call the API through the Web API without the order ID and confirm Dataverse rejects the request for the missing required parameter.