Jump to: navigation, search


< Zaqar
Revision as of 15:31, 23 July 2013 by Alejandro Cabrera (talk | contribs) (Add HTTP return codes.)


This page was created to capture the design considerations for a new metadata endpoint. First things first:

The goal of adding a metadata endpoint is twofold.

  1. Decouple metadata updates from queue creation.
  2. Decouple metadata (user-defined values) from configuration (server-defined values)

Decoupling Creation

While convenient, having queue creation tied to metadata updates forces (for certain storage engines) the metadata to be stored with the queue. This is currently optimal, but it limits us from changing this in the future.

Decoupling Metadata from Configuration

This is the more prominent of the two reasons. Currently, we want to define certain queue configuration parameters that affect all data stored in the queue. Example gives include:

  1. TTL: defines the default time-to-live for messages posted to this queue
  2. Max message size: different than the server default

We don't want these to collide with user-defined metadata, but we want users to be able to modify these values.


PUT /v1/queues/{name}

Two changes are required here:

  • Ignore anything placed in the message body. PUT does not update metadata.
  • At the storage layer, have the queue controller's upsert operation leave metadata alone.

HTTP 201 or 204

PUT /v1/queues/{name}/metadata

Used to update metadata. The queue body represents the new metadata.

HTTP 204 or 400 or 404 (400 on bad metadata)

GET /v1/queues/{name}/metadata

Used to fetch the metadata.

HTTP 200 or 404