zachjsh commented on PR #13165:
URL: https://github.com/apache/druid/pull/13165#issuecomment-1295494708
> Here's how we propose to revise the REST API. Comments or suggestions?
>
> Use a form of `{topic}/{path}`, where the topic is the kind of action.
This resolves the ambiguity of trying to do it the other way: `{path}/{action}`
where there is an ambiguity between paths and actions.
> ### Configuration-as-Code
>
> CRUD for an entire `TableSpec`, optionally protected by a version.
>
> `POST /resource/tables/{schema}/{table}[?version={n}|overwrite=true|false]`
>
> Create or update a `TableSpec`.
>
> * With no options, the semantics are "create if not exists."
>
> * With a version, the semantics are "update if exists and is at the
given version"
>
> * With "overwrite", the semantics are "create or update"
>
>
> `GET /resource/tables/{schema}/{table}`
>
> `DELETE /resource/tables/{schema}/{table}`
> ### Editing
>
> Edit operations apply a specific transform to an existing table spec.
Because the transform is very specific, there is no need for a version as there
is little scope for unintentional overwrites. The edit actions are usable from
the Druid console or DDL statements, if/when we add them.
>
> `POST /edit/table/{schema}/{table}`
>
> The payload is a message that says what to change:
>
> * Hide columns (add to the hidden columns list)
>
> * Unhide columns (remove from the hidden columns list)
>
> * Drop columns (remove items from the columns list)
>
> * Move columns
>
> * Update props (merge updated properties with existing)
>
> * Update columns (merge updated columns with existing)
>
>
> ### Retrieval
>
> `GET /names/schemas`
>
> Returns a list of the schema names.
>
> `GET /names/tables/{schema}`
>
> Returns a list of the table names within a schema.
>
> `GET /entry/tables`
>
> Returns a list of the metadata (`TableSpec` plus update dates, etc.) for
all tables.
>
> `GET /entry/tables/{schema}`
>
> Returns a list of the metadata for tables within a schema.
>
> `GET /entry/tables/{schema}/{table}`
>
> Returns the metadata for a single table.
> ### Sync
>
> `GET /sync/tables`
>
> Returns a list of `TableSpec` objects for bootstrapping a Broker.
>
> Similar to`GET /entry/tables`, but that message returns metadata.
>
> `POST /sync/delta`
>
> On the broker, receives update (delta) messages from the coordinator. The
payload is an object:
>
> * Create/update: table path plus the `TableSpec`
>
> * Delete: table path only
Thanks for updated proposal @paul-rogers . One thing I think would be good
is if in the URI path, when specifying a table within a specific schema, the
`schema` should come before `table` in the path, as is denotes a hierarchy,
tables within a schema, not the other way around. Anyway that we can do this?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
