In my opinion, the subsection "webhook vs websocket" could be moved to the Subscribing and Unsubscribing section

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Highest
    • FHIRCast (FHIR)
    • 0.1 [deprecated]
    • Imaging Integration
    • (NA)
    • Event Notification
    • Hide

      I agree that this can be and probably should be moved up since the decision for whether to use webhooks or websockets needs to be made at the subscribing stage of the workflow. I vote to move this description of the two communication methods up to the Subscribing and Unsubscribing section.

      Show
      I agree that this can be and probably should be moved up since the decision for whether to use webhooks or websockets needs to be made at the subscribing stage of the workflow. I vote to move this description of the two communication methods up to the Subscribing and Unsubscribing section.
    • Eric Martin / Bas van der Heuval: 6-0-0
    • Clarification
    • Non-substantive

      In my opinion, the subsection "webhook vs websocket" could be moved to the Subscribing and Unsubscribing section.

      Existing Wording:

      webhook vs websocket

      A subsciber specifies the preferred hub.channel.type of either webhook or websocket during creation of its subscription. Only the event notification and subscription denied exchanges are affected by the channel type. Subscribers SHOULD use websockets when they are unable to host an accessible callback url.
      Implementer feedback is solicited around the preference and desired optionality of webhooks and websockets.

            Assignee:
            Unassigned
            Reporter:
            Ricardo Quintano
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: