-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Description
After a lot of investigation and discussion with all party involved, drafting a spec for send
of EventGrid. We might be near to be done with @t-swpill work, but for clarity needs to be written:
We shall have ONE send
method only, that accepts different types of content:
- A CloudEvent instance
- A EventGridSchema instance
- A dict, or any type
- An explicit list of the three preceding format
For the later, we shall send the dict "as-is" on the wire, and not try any kind of client-side validation. Example, this is a valid way to send a Cloud Event:
client.send({
"id": "foo",
"source": "blo",
"specversion":"1.0",
"type": "blie",
"data": {"joy":True}
})
The dict follow the CloudEvent spec, so there is no reason to not send it that way.
Implementation (important) detail: when sending a CloudEvent, we must set the Content-Type to "application/cloudevents-batch+json; charset=utf-8". This means in the dict case, we must detect if the dict is Cloud Event. We recommend using a predicate that checks:
- All required Cloud Event attributest are provided: id/source/specversion/type
- specversion has the value "1.0"
If the dict follow this structure, we send the JSON with application/cloudevents-batch+json; charset=utf-8
, otherwise we use application/json
In case we want to be explicit:
client.send({
"id": "foo",
"source": "blo",
"specversion":"1.0",
"type": "blie",
"data": {"joy":True}
},
content_type="application/json"
)
And list are supported:
client.send([{
"id": "foo",
"source": "blo",
"specversion":"1.0",
"type": "blie",
"data": {"joy":True}
},{
"id": "foo",
"source": "blo",
"specversion":"1.0",
"type": "blie",
"data": {"joy":False}
}])