Page Comparison

...

Base URL: /v3/namespaces/<ns-id>

Create Topic

• Request method and URI
  • PUT [base_url]/topics/[topic]
• Request body
  • Can be empty
  • If provided, it is a JSON object containing topic properties

    • e.g. {"ttl" : [ttl-in-seconds]}

• Response
  • 200 OK if the topic was created successfully
  • 409 CONFLICT if a topic of the same name exists already
  • 400 BAD REQUEST if the given TTL is invalid

Update Topic

• Request method and URI
  • PUT [base_url]/topics/[topic]/properties

• Request body
  • JSON object containing topic properties. Note that this call will replace all the existing properties.
    

    • e.g. {"ttl" : [ttl-in-seconds]}

• Response
  • 200 OK if the topic properties were updated successfully
  • 404 NOT FOUND if the topic is not present
  • 400 BAD REQUEST if the properties were not correct

Delete Topic

• Request method and URI
  • DELETE [base_url]/topics/[topic]

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

Publish Message

There are two separate endpoints to support different publishing cases as described above. They both share the same request format.

• Request Schema

  • { "

    tx_write_ptr

    transactionWritePointer" : [ "

    string

    long", "null" ], "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)

    1. messages - Contains an array of byte arrays that correspond to messages

    ii) tx_write_ptr

    1. transactionWritePointer - Corresponds to a transaction write pointer.

     

Store Messages to Payload

...

Table 

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

• Request body should contain

  tx_write_ptr

  transactionWritePointer and messages
 

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

...

Publish 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_ptrwith same transactionWritePointer, then this endpoint should be called with an empty messages field. If it is not preceded by store calls to the same tx_write_ptrwith same transactionWritePointer, then this call will store the messages to  to the MessageTable
  directly.
• If the call does not contain a tx_write_ptr 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 tx_write_ptr and can optionally contain messages transactionWritePointer. If store calls were made previously with the same tx_write_ptr transactionWritePointer, 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

schema should contain tx_write_ptr and the messages field is ignored

Response:

404

• Schema

  • { "transactionWritePointer" : "long" }

• Response:

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

 

Consume Message

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

• Request Schema

  • { "messageId" : [ "bytes", "null" ], "timestamp" : [ "

    string

    long", "null" ], "inclusive" :

    [

     "boolean",

    "null" ],

     "limit" : [ "integer", "null" ], "transaction" : [ "bytes" , "null" ] }
     

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

  • { "

    response

    type" : "array", "items" : {"type": "

    array

    record", "

    items

    name": "

    record" }  }  - each record contains two fields - { "messageId" , "bytes", "message" : "bytes" }

     

• Request body
Can be avro binary or JSON, based on the

• • 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) messageId - Contains bytes that correspond to the messageId
  ii) timestamp - Timestamp in ms as a string
  iii) inclusive - boolean field that says whether the messageId/timestamp should be inclusive
  iv) limit - max number of responses to return
  v) transaction -  serialized bytes of the transaction object
   

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

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  

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

  • Response body contains an avro binary or JSON object based on the request Content-Type with the schema as mentioned above

...