Closed james-answer closed 5 years ago
Is there a way for a subscriber to decide which format they recieve the event message in, json or xml?
For example if a publisher sends out the event as JSON can a subscriber ask it to be sent to their mesh mail box as XML if they can not process JSON?
I would have thought if the EMS is adding the ITK wrapper it would be able to change the output format to one the subscriber requests.
Point 1 has been resolved.
All events will be received xml, a decision was made to support only one format for go-live. We may support json as part of a future release.
@fletch1975 - does the point around XML need to be made clear in the spec, perhaps under Event Receiver Requirements?
I assume this is relevant to all API's, the subscription, publication and the MESH reviever requirements so it might be appropriate to put something in a common area of the spec or in each of the seperate sections.
We also need to update all the examples as they are currently JSON and if we only accept XML then we should reflect that in the specification.
I have updated the subscription management pages so that examples are in XML and there is a note highlighting that the EMS only supports XML at the moment. I have also made a slight change to layout so that it reads more clearly. Changes committed to the "develop" branch.
DDC have highlighted that the NEMS supports XML and JSON for APIs but only sends events to subscribers in XML so updated the wording.
Closing as all points on this github issue have been addressed and merged.
On the page Create Subscription (https://developer.nhs.uk/apis/ems-beta/explore_create_subscription.html#pre-requisites):
there is something which looks like a mistake. In the subscription information table it has the following wording:
(currently only “mesh” is supported)
should this be:
(currently only "message” is supported)
as MESH is not a valid value within the valueset, message is the only valid value which is currently applicable.
The links out to spine core should be to a static version of the specification so that we are not referencing something which can cause a breaking change or affect peoples ability to interact with NEMS.
The url that the subscription has to be POSTed to is only shown in the example and should probably be called out at the top of the page in the "Creating a Subscription" section, before the "Subscription Resource" as it is key to the interaction.