This allows to correctly define REST operation where the schema of the message (request and/or reply) varies based on the value of a specified attribute. In the specification example, the message contains a “petType” attribute that can either be “cat” or “dog”. In each case, the content of the message is adjusted for attributes needed for one or the other type, in addition to shared attributes.
Our company used many REST services leveraging discriminator to limit the number of operations. However, PowerApps does not currently support this. As a workaround, we must create OpenApi specification files for each variations of the operation content and create a separate connector for each of them. Some operations have as many as 20 variations.
Using the same example as in the specification, we could have a single “save” REST operation that can save either cat or dog records, but we need to create two OpenApi files and the corresponding connectors: SaveCat and SaveDog. The correct OpenApi definition for this service should have a single “save” operation and use discriminator on the petType attribute to describe the message schema for each type.
In PowerApps, each operation of a service is exposed as a method of the connection, I understand that the validation of the request content in PowerApps as well as the type definition of the reply are based on this method (operation). I suggest that when discriminator is used, then the operation id (eg “save” in our example) be suffixed by the discriminator value to create a series of methods (“save_cat” and “save_dog” in our example) thus allowing correct validation and type definition.
This change will reduce (by a factor of about fifteen for our company) the numbers of connectors we need.