Services/MessageQueuing: Difference between revisions
mNo edit summary |
(updated page with new details and API proposal) |
||
Line 2: | Line 2: | ||
The '''Message Queue''' project is part of [[Services/Roadmap/Sagrada|Project Sagrada]] | The '''Message Queue''' project is part of [[Services/Roadmap/Sagrada|Project Sagrada]] | ||
, providing a service for applications to queue messages for | , providing a service for applications to queue messages for clients. | ||
The first version of the MQ will focus on providing a useful service for the | The first version of the MQ will focus on providing a useful service for the | ||
[[Services/Notifications|Notifications project]] to enqueue messages for many | [[Services/Notifications|Notifications project]] to enqueue messages for many | ||
queues and for | queues and for clients to poll for messages on a given queue. | ||
No message aggregation is done in this version, if a client needs to get | |||
messages for more than one subscription it must poll each queue and aggregate | |||
them. | |||
The first version could be considered a '''Message Store''' rather than a | |||
''queue'' as it supports a much richer set of query semantics and does not let | |||
public consumers remove messages. Messages can be removed via the entire queue | |||
being deleted by the App or by expiring. | |||
= Project = | = Project = | ||
Line 13: | Line 22: | ||
* Ben Bangert | * Ben Bangert | ||
== User Requirements == | |||
* Service App can create queues | |||
* Service App can add messages to queue | |||
* Messages on queues expire | |||
* Clients may read any queue they are aware of | |||
== Proposed API == | |||
For the first version, applications allowed to use the '''Message Queue''' | |||
will be given an application key that must be sent with every request, and | |||
their IP must be on an accepted IP list for the given application key. | |||
=== Internal Apps === | |||
'''POST /queue/new''' | |||
Creates a new queue, takes the queue name as POST param ''queue_name''. | |||
'''DELETE /queue/{queue_name}''' | |||
Deletes a given queue created by the App. | |||
'''POST /queue/{queue_name}/clear''' | |||
Clears the given queue of all messages, without deleting it. | |||
'''POST /queue/{queue_name}''' | |||
Create a message on the given queue. Contents is expected to be | |||
a JSON object. | |||
Raises an error if the queue does not exist. | |||
=== Clients === | |||
'''GET /queue/{queue_name}''' | |||
Returns all messages for the queue. Can optionally be passed | |||
one of several query parameters: | |||
''since_timestamp'' - All messages newer than this timestamp | |||
''limit'' - Only return N amount of messages | |||
Messages are returned in order of newest to oldest. | |||
== Use Cases == | == Use Cases == | ||
Line 27: | Line 84: | ||
* Devices can read the X most recent messages | * Devices can read the X most recent messages | ||
* Devices can read messages since XXX | * Devices can read messages since XXX | ||
* Messages are encoded as JSON |
Revision as of 18:52, 23 September 2011
Overview
The Message Queue project is part of Project Sagrada , providing a service for applications to queue messages for clients.
The first version of the MQ will focus on providing a useful service for the Notifications project to enqueue messages for many queues and for clients to poll for messages on a given queue.
No message aggregation is done in this version, if a client needs to get messages for more than one subscription it must poll each queue and aggregate them.
The first version could be considered a Message Store rather than a queue as it supports a much richer set of query semantics and does not let public consumers remove messages. Messages can be removed via the entire queue being deleted by the App or by expiring.
Project
Engineers
- Ben Bangert
User Requirements
- Service App can create queues
- Service App can add messages to queue
- Messages on queues expire
- Clients may read any queue they are aware of
Proposed API
For the first version, applications allowed to use the Message Queue will be given an application key that must be sent with every request, and their IP must be on an accepted IP list for the given application key.
Internal Apps
POST /queue/new
Creates a new queue, takes the queue name as POST param queue_name.
DELETE /queue/{queue_name}
Deletes a given queue created by the App.
POST /queue/{queue_name}/clear
Clears the given queue of all messages, without deleting it.
POST /queue/{queue_name}
Create a message on the given queue. Contents is expected to be a JSON object. Raises an error if the queue does not exist.
Clients
GET /queue/{queue_name}
Returns all messages for the queue. Can optionally be passed one of several query parameters: since_timestamp - All messages newer than this timestamp limit - Only return N amount of messages Messages are returned in order of newest to oldest.
Use Cases
Notifications
The new version of Notifications will use the MQ to store messages for users from various websites and allow users to poll the MQ directly for new notifications they have allowed.
- Internal app add's messages to a queue by queue name
- Internal app can delete queues by name
- Devices can read a queue by name
- Devices can read the X most recent messages
- Devices can read messages since XXX
- Messages are encoded as JSON