-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Parse LiveQuery Protocol Specification
Parse LiveQuery server has its own protocol. It is built on top of standard WebSocket connections. A client should follow this protocol to interact with the LiveQuery server. This protocol defines the messages to connect to the LiveQuery server, subscribe/unsubscribe a ParseQuery
and get updates from the LiveQuery server. The clients and the server communicate with each other in messages. Each message is a compacted JSON object.
The connect message is sent from a client to the LiveQuery server. It should be the first message sent from a client after the WebSocket connection is established. The connect message's format is:
{
"op": "connect",
"applicationId": "",
"restAPIKey": "", // Optional
"javascriptKey": "", // Optional
"clientKey": "", //Optional
"windowsKey": "", //Optional
"masterKey": "", // Optional
"sessionToken": "", // Optional
"installationId": "" // Optional
}
- The
op
field must beconnect
. - The key field is optional. When you initialize the LiveQuery server with key pairs, the LiveQuery server will try to match the key field in the connect message with the given key pairs. If no key pair is provided when the LiveQuery server is initialized, the key field will be ignored.
- The
sessionToken
field is optional. If you provide thesessionToken
, when the LiveQuery getParseObject
's updates from parse server, it will try to check whether thesessionToken
fulfills theParseObject
's ACL. The LiveQuery server will only send updates to clients whosesessionToken
is fit for theParseObject
's ACL. - The
installationId
field is optional. InstallationId is a identifier for a device. It can be used for monitoring.
If a client connects to the LiveQuery server successfully, it will receive a response like
{
"op": "connected"
}
After a client connects to the LiveQuery server, it can send a subscribe message to subscribe a ParseQuery
. The message's format is:
{
"op": "subscribe",
"requestId": 1,
"query": {
"className": "Player",
"where": {"name": "test"},
"fields": ["name"] // Optional
},
"sessionToken": "" // Optional
}
- The
op
field must besubscribe
. - The
requestId
field is mandatory. It is a number which is unique for each LiveQuery subscription. The LiveQuery server will use this to distinguish between the different subscriptions from the same client. - The
query.className
field is mandatory. It represents the className of theParseQuery
the client subscribes to. - The
query.where
field is mandatory. It represents the condition of theParseQuery
the client subscribes to. The format of the where field is the same withParseQuery
's REST API format. You can check the detail here. Right now we support$lt
,$lte
,$gt
,$gte
,$ne
,$in
,$nin
,$exists
,$all
,$regex
,$nearSphere
,$within
and normal equal condition. Any unsupported conditions will be ignored. - The
query.fields
field is optional. It is an array of field names of aParseObject
. Suppose theParseObject
Player
contains three fieldsname
,id
andage
. If you are only interested in the change of thename
field, you can setquery.fields
to[name]
. In this situation, when the change of aPlayer
ParseObject
fulfills the subscription, only thename
field will be sent to the clients instead of the fullPlayer
ParseObject
. - The
sessionToken
field is optional. It is similar to thesessionToken
field in the connect message. ThesessionToken
field in subscribe message has higher priority than thesessionToken
field in connect message. This means the LiveQuery server will try to use thesessionToken
in subscribe message to check aParseObject
's ACL first.
If a client subscribes a ParseQuery
to the LiveQuery server successfully, it will receive a response like:
{
"op": "subscribed",
"requestId":1
}
Once a client get this response from the LiveQuery server, it will start to receive ParseObject
s whose changes fulfill the ParseQuery
.
After a client subscribes to a ParseQuery
, the LiveQuery server will send event messages to the client. We support 5 types of events. Suppose you subscribe to a ParseQuery
like:
{
"op": "subscribe",
"requestId": 1,
"query": {
"className": "Player",
"where": {"name": "test"}
}
}
This event means a ParseObject
is created and it fulfills the ParseQuery
the client subscribes.
When a new Player
ParseObject
whose name is "test" is created, the LiveQuery server will send a create
event message to the client. The create
event message's format is:
{
"op": "create",
"requestId": 1,
"object": {
"className": "Player",
"objectId": "",
"createdAt": "",
"updatedAt": "",
...
}
}
- The
op
field iscreate
. - The
requestId
field is a numebr. It is same as therequestId
when the client subscribes theParseQuery
to the LiveQuery server. - The
object
is theParseObject
in JSON format.
This event means a ParseObject
's old value does not fulfill the ParseQuery
but its new value fulfills the ParseQuery
. When an existing Player
ParseObject
's name is changed from unknown to test, the LiveQuery server will send an enter
event message to the client. The enter
event message's format is:
{
"op": "enter",
"requestId": 1,
"object": {
"className": "Player",
"objectId": "",
"createdAt": "",
"updatedAt": "",
...
}
}
This event means a ParseObject
's old value and its new value fulfill the ParseQuery
at the same time. For an existing Player
ParseObject
' whose name is "test", when its age changes from 20 to 21, the LiveQuery server will send an update
event message to the client. The update
event message's format is:
{
"op": "update",
"requestId": 1,
"object": {
"className": "Player",
"objectId": "",
"createdAt": "",
"updatedAt": "",
...
}
}
This event means a ParseObject
's old value fulfills the ParseQuery
but its new value does not. When an existing Player
ParseObject
's name is changed from test to unknown, the LiveQuery server will send a leave
event message to the client. The leave
event message's format is:
{
"op": "leave",
"requestId": 1,
"object": {
"className": "Player",
"objectId": "",
"createdAt": "",
"updatedAt": "",
...
}
}
This event means a ParseObject
's whose value fulfills the ParseQuery
is deleted. When an existing Player
ParseObject
's whose name is "test" is deleted, the LiveQuery server will send an delete
event message to the client. The delete
event message's format is:
{
"op": "delete",
"requestId": 1,
"object": {
"className": "Player",
"objectId": "",
"createdAt": "",
"updatedAt": "",
...
}
}
The unsubscribe message is sent from clients to the LiveQuery server. It should be sent after a client successfully unsubscribes some ParseQuery
. The format of the unsubscribe message is:
{
"op": "unsubscribe",
"requestId":1
}
- The
op
field isunsubscribe
. - The
requestId
field is mandatory. It is a number which is unique for each LiveQuery subscription. It is the samerequestId
when the client subscribes theParseQuery
to the LiveQuery server.
If a client unsubscribes a ParseQuery
to the LiveQuery server successfully, it will receive a response like:
{
"op": "unsubscribed",
"requestId":1
}
When a client sends unknown or error messages to the LiveQuery server, the server will respond with an error message to the client. The format of the error message is:
{
"op": "error",
"code": 1,
"error": "",
"reconnect": true
}
- The
op
field iserror
. - The
code
field is a number which represents the type of the error. - The
error
field is the error message. - The
reconnect
field is a boolean which indicates whether a client can reconnect to the LiveQuery server after this error. Most of the cases it istrue
. But if the LiveQuery server has some internal errors, it can befalse
. If it isfalse
, a client should not try to reconnect to the LiveQuery server.