AdminAPI could be more RESTFUL #378

New Issue

Open

opened 2022-09-12 11:14:22 +00:00 by quentin · 0 comments

quentin commented

2022-09-12 11:14:22 +00:00

Owner

Instead of mapping directly to the CLI commands and to a RPC model, we could have a more restful approach.

We could replace /status and /connect with a /member, /membership, /fleet or something similar.

POST would be used to add members
GET would be used to get members status (without the layout)

For the layout part, we could also have a single /layout endpoint:

GET would return the current and staged layout, as currently
PATCH or PUT could be used to change the staged layout (UpdateClusterLayout)
DELETE could be used to revert change on the staged layout (RevertClusterLayout)
POST could be used to apply the staged layout (ApplyClusterLayout)

For the key part, we could have a /key/{pattern} approach:

GET /key would return the list of all keys
GET /key/{pattern} would fetch the first key matching the pattern. ?exact or something similar could be appended to find the exact identifier and thus benefit from the optimization
POST /key would be used to add a new key. Adding ?import could be used to import the key instead of generating a new one.
PATCH /key/{identifier} (or PUT) could be used to update a key
DELETE /key/{identifier} would be used to delete the key

The same logic could be used for the bucket endpoints but I have not reviewed them yet...

Also, sometimes we pass small parameters in the body:

{ "version": 13}

But sometimes not:

DELETE /key?id=xxx

Instead of mapping directly to the CLI commands and to a RPC model, we could have a more restful approach. We could replace `/status` and `/connect` with a `/member`, `/membership`, `/fleet` or something similar. - `POST` would be used to add members - `GET` would be used to get members status (without the layout) For the layout part, we could also have a single `/layout` endpoint: - `GET` would return the current and staged layout, as currently - `PATCH` or `PUT` could be used to change the staged layout (`UpdateClusterLayout`) - `DELETE` could be used to revert change on the staged layout (`RevertClusterLayout`) - `POST` could be used to apply the staged layout (`ApplyClusterLayout`) For the key part, we could have a `/key/{pattern}` approach: - `GET /key` would return the list of all keys - `GET /key/{pattern}` would fetch the first key matching the pattern. `?exact` or something similar could be appended to find the exact identifier and thus benefit from the optimization - `POST /key` would be used to add a new key. Adding `?import` could be used to import the key instead of generating a new one. - `PATCH /key/{identifier}` (or `PUT`) could be used to update a key - `DELETE /key/{identifier}` would be used to delete the key The same logic could be used for the bucket endpoints but I have not reviewed them yet... Also, sometimes we pass small parameters in the body: ```json { "version": 13} ``` But sometimes not: ```json DELETE /key?id=xxx ```