Page Comparison

...

• Request method and URI

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

• Request

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

  • 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).

• 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" : "PublishResponse", "fields" : [ { "name" : "transactionWritePointer", "type" : [ "long", "null" ] }, { "name" : "messagesstartTimestamp", "type" : { "type" : "array""long" }, "items" : { "typename" : "recordstartSequenceId", "nametype" : "MessageInfoint" }, "fields" : [ { "name" : "publishTimestampendTimestamp", "type" : "long" }, { "name" : "sequenceIdendSequenceId", "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.

...