Page Comparison

...

• Response
  • 200 OK if the topic was deleted successfully
  • 404 NOT FOUND if the topic is not present

Publish Message

Store Messages to Payload Table 

• Request method and URI
  • POST [base_url]/topics/[topic]/publishstore
 
• Request bodyJSON object containing payload and optionally transaction write pointerSchema

  • {

    "payload

    "

    : [ payload byte array ], "

    tx_write_ptr

    " : 12345L,  "buffer" : true }

    Fields" : string, "messages" : { "type" : "array", "items" : "bytes" }}

• Request body
  • Can be avro binary or JSON, based on the request - Content-Type: application/json or avro/binary

  • Schema Fields:
    i) payload messages - Contains the payload in the form of an array of bytesbyte arrays that correspond to messages
    ii) tx_write_ptr (optional) - Contains a long that corresponds - Corresponds to a transaction write pointer. If this field is not provided, then the publishing of message is performed non-transactionally
    iii) buffer (optional) - A boolean flag that indicates whether the messages can be buffered on the client side or should it the message be persisted in a Payload table. This option is not used when tx_write_ptr is not set (i.e., if the message is published non-transactionally)
     

  Response :
  404 NOT FOUND if the topic is not present
  200 OK if message is persisted
  Commit Transactionally published messages

• Response :
  404 NOT FOUND if the topic is not present
  200 OK if message is persisted
  
  

Commit Messages to Message Table 

• This call can be preceded by multiple calls to the 'store' endpoint. If it is preceded by calls to store to the same tx_write_ptr, then this endpoint should be called with an empty messages field. If it is not preceded by store calls to the same tx_write_ptr, then this call will store the messages to the MessageTable
  directly.
• If the call does not contain a tx_write_ptr, then the messages are stored non-transactionally (ie, without a tx write ptr).
  
  
  • POST [base_url]/topics/[topic]/commit

    Request body should contain the transaction write pointer that should be committed

    { "publish
 

  • Request schema can optionally contain tx_write_ptr and can optionally contain messages. If store calls were made previously with the same tx_write_ptr

    " :  12345L }

    , the messages array should be empty.

    Response :

    404 NOT FOUND if topic is not present
    200 OK if messages are persisted

     

Rollback Transactionally published

...

messages 

• • POST [base_url]/topics/[topic]/rollback

  • Request

body

• • schema should contain

the transaction write pointer that should be rolled back{ "

• • tx_write_ptr

" :  12345L }

• • and the messages field is ignored

    Response

• • :

    404 NOT FOUND if topic is not present
    200 OK if messages are rolled back

TBD: When or should the client retry? If it could not be rolled back, the transaction should be invalidated.

Consume Message

• Request method and URI
  • POST [base_url]/topics/[topic]/poll
• Request body

  • An optional JSON object that contains the offset (either messageId or timestamp) and limit

    { "messageId" : [ message id byte array ], "timestamp" : 12454L,  "inclusive" : true, "limit" : 40, "transaction" : [Serialized Transaction Object] }
    
    

    Fields (all the fields are optional):
    i) messageId: Provide a messageId as an offset into the topic message queue
    ii) timestamp: Provide a timestamp as an offset into the topic message queue. Note that either messageId or timestamp needs to be provided. If both are provided, then messageId will be used.
    iii) inclusive: This boolean flag indicates whether the offset is inclusive or exclusive
    iv) limit: Max number of messages to return, by default it is set to 100.
    v) transaction: If message polling needs to be done transactionally, then this  

...