- New methods in CloudEventFormatter to support inference
- JsonEventFormatter infers a content type of application/json for non-binary data
- All transports use the inferred content type when formatting in binary mode
- Documentation for both formatters and bindings has been updated
Signed-off-by: Jon Skeet <jonskeet@google.com>
- Make "JSON media type detection" configurable, and default to */json and */*+json
- Default to JSON content type (including making it present in the serialized event)
- Make a "binary vs non-binary" distinction as the first part of serialization (instead of as a fallback)
- Deserialize string data values regardless of content type
- Prohibit non-string data values for non-JSON content types
Signed-off-by: Jon Skeet <jonskeet@google.com>
This requires a few nullable-reference-type overrides in tests where
we're absolutely confident they won't be null (and if we're wrong,
an NRE is fine to break the test).
Signed-off-by: Jon Skeet <jonskeet@google.com>
This sometimes feels a little cumbersome, with conversions that will
*sometimes* involve copying data, but leaves room for optimization
later and is a more flexible API in the long term.
Signed-off-by: Jon Skeet <jonskeet@google.com>
This leads to two different formatters both called
JsonEventFormatter, just in different namespaces. That probably
wouldn't cause too much ambiguity, as few applications would depend
on both packages. It avoids longer names such as
"SystemTextJsonEventFormatter" which is pretty unwieldy.
Both the implementation and the tests are very much based on the
Newtonsoft.Json implementation.
Fixes#42.
Signed-off-by: Jon Skeet <jonskeet@google.com>
Jon Skeet