Skip to content

Callback key can be a string with embedded RuntimeExpression #287

Description

@PerthCharern

Darrel (@darrelmiller)

Issue from Erik Petersen (@epet), Shweta Patil (@Shwetap05)

Currently we only allow RuntimeExpression in a key in a Callback object.

        /// <summary>
        /// A Path Item Object used to define a callback request and expected responses.
        /// </summary>
        public Dictionary<RuntimeExpression, OpenApiPathItem> PathItems { get; set; }
            = new Dictionary<RuntimeExpression, OpenApiPathItem>();

This is not correct given an example in the spec: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#callback-object-example

myWebhook:
  'http://notificationServer.com?transactionId={$request.body#/id}&email={$request.body#/email}':
    post:
      requestBody:
        description: Callback payload
        content: 
          'application/json':
            schema:
              $ref: '#/components/schemas/SomePayload'
      responses:
        '200':
          description: webhook successfully processed and no retries will be performed

Note that the "expression" key above is a URL with RuntimeExpression embedded in.

Note: I think the spec is a bit ambiguous. The spec states this: "The key that identifies the Path Item Object is a runtime expression that can be evaluated in the context of a runtime HTTP request/response to identify the URL to be used for the callback request."

The runtime expression in the spec is strictly defined. There's a bit of leeway with this sentence "Runtime expressions preserve the type of the referenced value. Expressions can be embedded into string values by surrounding the expression with {} curly braces.", but this sentence is in the Examples section of runtime expression section and it contradicts with the definition of runtime expression directly above: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#examples-1

I would say we are actually faithful to the spec with the current implementation - though probably not aligned with the spirit of the spec.

Metadata

Metadata

Labels

type:bugA broken experience

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions