Link Object (and Arazzo?): require referencing operation with unambiguous path template

[ralfhandl]

Assume paths /foo and /bar both have a Path Item Object that $ref the same external "complete" Path Item Object.

If a Link Object now operationRefs the get Operation Object within that external Path Item Object, which request should the client construct?

It could be both

• GET /foo or
• GET /bar

Proposal:

• Add restriction to Link Object that operationRef and operationId MUST NOT reference a reusable/multi-used Path Item Object
• Possibly: require that the operationRef value "goes through" a Paths Object

[handrews]

I wonder if it would be better to set an operationIdPrefix alongside a Path Item $ref so that the operationIds could be made unique. This is not the most intuitive or obvious thing, but it would avoid having to come up with a new concept of referencing through another reference.

It would also help other operationId use cases such as Arazzo (and Overlay?)

[karenetheridge]

I don't understand how there is a problem here. $operationRef is a uri reference that is not relative to the path item it is part of, but the identifier being used in the local scope (and in the case of an OAD, where $id keywords aren't supported, it would be the resolved form of $self, or the identifier assigned to the document itself - as described in Appendix F).

$operationRef doesn't change whether the operation was reached via path /foo or path /bar.