Skip navigation.

Messages

Specification vs Instantiation vs Transport

Bayeux messages:

  • 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:

{channel:"/some/channel",data:[1,2,3]}

This message has a natural instantiation in Javascript. The message could be transported as a wire format that uses the JSON as described above, or the instantiated Javascript objects could be serialized to XML if some transport wished. If delivered to a Java Bayeux implementation, then the message would be instantiated as a java.util.Map<String,Object> instance that contained java.lang.String keys and values of type java.lang.String and java.util.Array<Object>.

Reserved Fields

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:

channel
All messages MUST have a channel field with a string value that identifies the handler for the message.
clientId
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.
id
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.
data
The message payload. An arbitrary object
advice
Transport-specific parameters.
ext
Extension space
successful
Indicates the success of a protocol operation. Used in a response message
error
Error code and message