thanks. i think this make sense. i'm thinking we should just use repeated queryparams for this, so `?expand=status&expand=config`
another thing is what do you think we should use for the `/` endpoint? was thinking `?expand=info` output could look like w:kafka norwood$ curl -s ' http://localhost:8083/connectors?expand=status&expand=config' | jq { "blah": { "config": { "name": "blah", "config": { "connector.class": "org.apache.kafka.connect.file.FileStreamSourceConnector", "file": "/tmp/lol", "tasks.max": "10", "name": "blah", "topic": "test-topic" }, "tasks": [ { "connector": "blah", "task": 0 } ], "type": "source" }, "status": { "name": "blah", "connector": { "state": "RUNNING", "worker_id": "10.200.25.241:8083" }, "tasks": [ { "id": 0, "state": "RUNNING", "worker_id": "10.200.25.241:8083" } ], "type": "source" } } } will update the wiki with this info thanks dan On Thu, May 2, 2019 at 4:43 PM Alex Liu <alex....@confluent.io> wrote: > Good idea, Dan. One thing I might suggest is to have the query parameters > reflect the fact that there are multiple resources under each connector. > There is `connectors/<name>/`, `connectors/<name>/config`, and > `connectors/<name>/status`. > Each of them returns a slightly different set of information, so it would > be useful to allow the query parameter be a string instead of a true/false > flag. In this case, `expand=status,config` would specify expanding both the > /status and /config subresources into the response objects. > > Other than this detail, I think this is a useful addition to the Connect > REST API. > > Alex >
