What you’re describing is possible, but I think that writing a client application would be much simpler. You could use a consumer to read from the topic, use the values to make the web service call, then use a producer to write the results to the target topic. Is there a reason you’d like to avoid running a client application?
Thanks, Dave. My client is looking for a minimal code solution (they are a .net house). I am leveraging KSQLDB and Connect for most of the work. The fact that I could leverage some code from an existing connector and modify it and just pop it into connect would be the ideal solution for me.
The end client is weighing up a custom .net solution via Kafka. Having the connector configurable via rest would keep the solution appealing to them. The whole solution would be made up of connectors and KSQLDB which reduces the number of moving parts.
I am working on a proof of concept where they are more likely to go with Kafka if things are neat and tidy. So while I don’t rule out writing a client app I was hoping to keep things in the Connect/KSQL domain.
In that case, what you are suggesting might be a good way to go. At a minimum it sounds like a lot of fun! If you don’t mind, it would be great if you can post back here, and let us know how it worked out.