Page Comparison

...

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

  • Request schema can optionally contain transactionWritePointer. If store calls were made previously with the same transactionWritePointer, the messages array should be empty.

    Response:

    404 NOT FOUND if topic is not present
    200 OK if messages are persisted
    400 BAD REQUEST if the {{transactionWritePointer}} is null and the messages field is empty. Messages field can be empty if the transactionWritePointer is provided

    Response Body:
    
    

    • If the publish is non-transactional, the response body is empty

    • If the publish is transactional, the response body will contains the information needed for rollback with the following schema

      Code Block
      language js
      { "type" : "record", "name" : "PublishedInfoPublishResponse", "fields" : [ { "name" : "transactionWritePointer", "type" : [ "long", "null" ] }, { "name" : "messages", "type" : { "type" : "array", "items" : { "type" : "record", "name" : "MessageInfo", "fields" : [ { "name" : "publishTimestamp", "type" : "long" }, { "name" : "sequenceId", "type" : "int" } ] } } } ] }

    • The client shouldn't need to parse the response body, but rather treats it as opaque bytes. On rollback, simply use it as the request body.

...

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


• Request Schema

  Code Block
  language js
  { "type" : "record", "name" : "ConsumeRequest", "fields" : [ { "name" : "startFrom", "type" : [ "bytes", "long", "null" ] }, { "name" : "inclusive", "type" : "boolean" }, { "name" : "limit", "type" : [ "integer", "null" ] }, { "name" : "transaction", "type" : [ "bytes", "null" ] } ] }

   

• Response Schema (will be in JSON or Avro binary based on the request Content-Type)

  Code Block
  language js
  { "type" : "array", "items" : { "type" : "record", "name": "Message", "fields": [ { "name" : "id" , "type" : "bytes" }, {"name" : "payload" : "type" : "bytes"

   

  }

  ] }} 

  ] } }

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

• Schema Fields:
  i) startFrom - can be bytes in which case it is considered as messageId, can be long in which case it is considered as timestamp
  ii) inclusive - boolean field that says whether the messageId/timestamp should be inclusive
  iii) limit - max number of responses to return [an hard limit will be set by the TransactionServer which will be a cConf property]
  iv) transaction -  serialized bytes (TransactionCodec) of the transaction object

...