feature-request: server generated ids

[NeilDarach]

Allow producers to create tasks with a well-known id that will be interpreted by the server as a request for a server-generated id (in this example '0').

Update responses would include a list of ids alongside the counts, corresponding to the tasks submitted. Supplied ids would just be reflected back.

Calling

$ curl -X POST -d '{"payload": "hello world"}' "http://127.0.0.1:8000/v1/topics/example/tasks/0"

adds a task and has a response like

{"created":1,"updated":0,"ids":["52acfef8-d77e-45ff-aff9-4780ca414be1"]}

{
   "_id": "52acfef8-d77e-45ff-aff9-4780ca414be1",
   "topic": "example",
   "state": 0,
   "nonce": "",
   "produced": "2022-09-21T10:12:23.065074065Z",
   "scheduled": "2022-09-21T10:12:23.065074065Z",
   "payload": "hello world"
}

[peakji]

Allow producers to create tasks with a well-known id that will be interpreted by the server as a request for a server-generated id (in this example '0').

Instead of repurposing a specific ID, a less ambiguous approach would be allowing tasks to omit IDs when using batch insert. Currently tasks with empty IDs will cause Ratus to return a 400 Bad Request, it is quite easy to replace the error check with a server-side UUID generation process. We did not choose to do this for two reasons:

1. UUIDs can be easily generated on the server-side, but perhaps some users want more control over the scheme of the generated IDs (e.g., incremental IDs, timestamps), and some of these schemes cannot be efficiently implemented across existing storage engines.

2. Omitting IDs is perfectly fine in insert operations, but is likely to cause ambiguity in batch upsert operations.

Therefore, for the time being, the user is required to explicitly specify the task ID before inserting. The most likely improvement for this would be adding an option for ID generation scheme (may be limited to UUID only at the beginning).

Update responses would include a list of ids alongside the counts, corresponding to the tasks submitted. Supplied ids would just be reflected back.

This is a good idea and is in line with REST best practices. We will implement this improvement after we figured out a comprehensive solution for server-side ID generation. Thanks, @NeilDarach !