Specification vs Instantiation vs Transport
- are specified in JSON.
- should be instantiated in the natural object representation of the language used for the client/server.
- may be transported via any appropriate serialization that the specific transport supports. This may be a JSON String, an XML document or some other serialization.
A simple Bayeux message could be specified as:
java.util.Map<String,Object> instance that contained
java.lang.String keys and values of type
All fields in the top level of a JSON message are reserved for the use of the protocol. The following fields are the most important defined fields:
- All messages MUST have a channel field with a string value that identifies the handler for the message.
- A message MAY have a clientId field with a string value that identifies the client. ClientIDs are only unique within a single non-cluster Bayeux server and are only valid for the duration of the Bayeux connected state. They should be considered roughly equivalent to a HTTP session ID and treated the same with regards to security and longevity.
- Any message MAY contain an id field with a string value that identifies the message. The id is generated by the creator of the message and its uniqueness or otherwise is application-specific.
- The message payload. An arbitrary object
- Transport-specific parameters.
- Extension space
- Indicates the success of a protocol operation. Used in a response message
- Error code and message