Response Conditions represent the prerequisites for the response to be returned. Defining conditions makes it easy for you to have multiple responses for the same route that make sense.
Other than two special cases, one being having the “Default Response” set to true, and the other being having only one response defined for the route without conditions, condition matching will be the only thing that will determine what response is going to be returned. With conditions. testing negative paths, like a missing parameter, or testing positive paths like creating multiple resources, is easy. Response conditions are basically JSON object that defines what to look for in your request. You can define Header, Query String, Body and Origin based conditions.
The condition is defined by it’s Source, Kind and Value properties. Source represents the holder of the information to verify. For headers it’s the header name. For body depending on the content-type header it can be the JSON Path to the property, or the form name value. There are also two special values
$$body$$ (which seeks through the entire body) and
$$size$$ (which runs comparison against the body size). For the origin it’s not used because we analyze the Origin header from the request. For the query string it’s the name of variable and value.
The Kind property represents the comparison for the value. It can be of values exists|nexists|eq|contains|neq|ncontains|gt|lt. The gt and lt are only used with the special value
$$size$$ and the rest are used for all of the other conditions. The Value holds the value to compare against.
If you set multiple conditions as of right now they will be treated as AND conditions. The first response with most satisfying conditions is selected. If you have multiple responses with x matching conditions the first one will be returned.