Hi @RomanHotsiy,

The goal here it to allow short hand replacement of values without necessarily having to construct the full request structure. In situations where many of the request values support defaults this can be useful. Use pointers for cases where only parts of the body need to be dynamically changed or set, which is useful in complex workflows where subsequent steps might only modify a small portion of the data structure based on prior outputs.

I agree it should not enforce mutually exclusivity with payload as I can see situations where you might set the payload from and output variable from a previous step (e.g. a full response body) and then you may need to just change a value rather than being forced to construct the full shape of the payload again.

I can issue a PR to remove this restriction.

Regarding the ambiguity, that all depends on the schema of the requestBody.

pointers:

• target: /0
  value: 22
  Should it result in:

[22]
or

{
"0": 22
}

If the expected shape of the request was as follows then 22 would be set as the first item in the array:

[10, "foo", "bar"]

If the expected shape of the request as as follows then the value property 0 would set as 22:

{
 "0": 0,
 "1": 1
}

I also find this line contradicting: "which MUST be resolved against the request body."

Can you provide more detail here? When evaluating the JSON Pointer, it must be resolved against JSON contents. The JSON is expected to conform to the schema of the request body. We are not expecting an attempt to resolve against anything other than the request body. When we remove the mutual exclusivity constraint with payload we could change to "MUST be resolved against the request body (or payload which is a value representing the request body)"

Also, I find the pointers name to be misleading. When I first saw it I couldn't understand it. What about some other names like patches, updates?

Naming is never easy. I think pointer is sufficiently clear but I'm open to improvements but I would stay clear of patches. targets or injections might work better 🤔

What is the behavior if there is no payload supplied?

changes or replacements for possible naming candidates?

What if you have to remove one property from a payload?

What is the behavior if there is no payload supplied?

The request is constructed via a combination of schema defaults and the pointers supplied.

changes or replacements for possible naming candidates?

Yes, these are all possible names.

What if you have to remove one property from a payload?

Not currently supported. The only option would be to construct the explicit request using the payload. I do see some value in supporting this. Do you have specific needs for it?

The request is constructed via a combination of schema defaults and the pointers supplied.

But what if schema defaults are not provided or schema is not provided? Or if the schema is oneOf/anyOf with two options: object or array.

But what if schema defaults are not provided or schema is not provided? Or if the schema is oneOf/anyOf with two options: object or array.

The expectation is that a constructed request body can be accepted by the operation. If there is a situation where that is not possible with pointers then it would be more appropriate to use payload.

@RomanHotsiy hopefully #183 improves clarity here. I also renamed pointers to replacements from one of the suggestions by @adamaltman

@frankkilcommins yes, this sounds better. Thanks!