Hello everyone,
I am looking into the v2 API and I was wondering what our final design will
look like in terms of single- and multi-node setups.
The main question I am trying to answer for myself is "Do we need to
distinguish between the operation mode at API endpoints"?
>From what I can see in the API proposals and current state, some API
endpoints operate inside a cluster context (like /api/cluster/properties),
some inside a node context (like /api/node/logging), some other in cluster
node context (like /api/cluster/nodes/{nodeName}/roles), and some in no
context (which is I believe cluster and node, depending on operation mode?,
like in /api/aliases/{aliasName}/properties).
>From a consumer's point of view, this may be a bit irritating, and without
having worked on the API before and without participating in any prior
discussions, I would believe that it could be simplified.
Looking into where we are now and what we may expect from Solr in the
future, we may not have to distinguish between the operation modes at the
API endpoints. I am not aware of the historical background or any
constraints that probably apply, so please educate me.
>From what little I know, the following changes would make sense to me:
- GET /api/cluster/properties could be just GET /api/properties
- it would get the properties of Solr. If it is a cluster, whether it is
a single node or multiple, it should not make a difference
- GET /api/node/logging/messages could be
/api/nodes/{nodeId}/logging/messages
- It would get the log messages of a specific node. For single node
setups, the node ID is always the same, for multi-nodes it would have
different node IDs
- PUT /api/logging/levels could be added to reflect a cluster-wide log
level configuration, which seems to be missing in the v2 API at the moment
of writing
- GET /api/cluster/nodes/{nodeId}/roles could be /api/nodes/{nodeName}/roles
- it would return the roles of a specific node (if the roles are per node
configured)
- GET /api/aliases/{aliasName}/properties would stay as is, as it is
node-independent and therefore a nice and simple endpoint
This way we would reduce the complexity of our API (for the consumers) and
make it more intuitive. Additionally, the consumers would not need to know
whether there are multiple nodes or a single node running Solr, and will
always have a "collection of nodes", even if that collection contains only
a single node at times. And when scaling from one node to multiple nodes,
no changes at the consumer's side are required (which I'm not sure if this
is currently the case).
What prevents us from moving towards that direction?
Best,
Christos
