Skip to content

CloudEvent must be an abstraction of the spec, and not JSON specific #12959

@lmazuel

Description

@lmazuel

Again, I'm not saying the current prototype is incorrect, but writting this issue so I'm sure we address the spec explicitly.

Cloud Event is an abstraction of what is an event: https://github.com/cloudevents/spec/blob/v1.0/spec.md

As so, our CloudEvent class should not assume any serialization of a CloudEvent concept, and model the concept without thinking about the serialization. This implies:

  • There should be no data_base64 attribute, but helpers to set bytes correctly
  • Extensions should be treated as explicit extensions (and not simple new attributes at the base level).

Example:

c = CloudEvent(
    id=12,
    source='MyApp',
    type='CreateStuff'
)  # specversion is set by default to "1.0"

c.subject = "mynewfile.jpg"  # I could have set it as kwargs, but for the sake of sample

# Set data. API here could be discuss, we could use `data` property setter for instance
c.set_bytes_data(b"PDF%...", "application/pdf")

# Extensions are allowed aside, to avoid collision
c.extensions["reasonCode"] = 204

c.model # Returns the deserialized model

A JSON serialization of this would be:

{
    "id": 12,
    "source": "MyApp",
    "type": "CreateStuff",
    "subject": "mynewfile.jpg",
    "datacontenttype": "application/pdf",
    "data_base64": "ABCDEF_BASE64_OF_PDF",
    "reasonCode": 204
}

While a binary mode serialization would be HTTP request

ce-id: 12
ce-source
ce-source: MyApp
ce-type: CreateStuff
ce-subject: mynewfile.jpg
ce-datacontenttype: application/pdf
ce-reasonCode: 204

PDF%...

Metadata

Metadata

Labels

ClientThis issue points to a problem in the data-plane of the library.Event GridMessagingMessaging crew

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions