I thought the purpose of structured events was to more easily pass CloudEvents in a transport agnostic manner. If so, shouldn't the API be shaped towards that use case?

A user does not need to know if the event is structured or binary when creating a cloudevent with this framework. For example, this sample server will internally decipher both binary and structured events.

There may exist a use case in which a user may want to determine if some request is binary or structured (possibly testing/debugging purposes). Additionally, I'm not all too familiar with the other protocols but I suspect the current implementations for is_binary and is_structured are oriented towards http specific fields. Therefore I wanted to export these fields to the http module. Such that a user could easily access these methods if they wanted to do so, and the methods are in the more appropriate http namespace.

Let me know if that addressed your question!

After further conversation, I understand that binary and structured events are defined per transport type, so including them in http makes sense.