Our Community is getting an upgrade! To get everything ready for the relaunch, we’ll be placing the site in read-only mode starting September 21st.
We really appreciate your understanding while we get things set up behind the scenes. Catch up on all the exciting details about the move here.
Need help or have questions? Drop us a line at [email protected]

Archives of Support Questions (Read Only)

This is an archived board for historical reference. Information and links may no longer be available or relevant
Announcements
This board is archived and read-only for historical reference. To ask a new question, please post a new topic on the appropriate active board.

REST API /controller/search-results query syntax?

avatar

https://nifi.apache.org/docs/nifi-docs/rest-api/index.html

I can pull all of the data about a NiFi data flow using the /controller/search-results api call, but the request section also mentions a 'q' parameter (for query). There was no mention of the query syntax in the doc, however, any pointers? Would like to avoid pulling in a full config every time and parse on a constrained device, if possible.

1 ACCEPTED SOLUTION

avatar
Expert Contributor

The 'q' parameter is free-form (though URL encoded since it's part of the URL) and is whatever text you are searching for. For instance, it could be the UUID of a Processor, a Property Name or value, etc. If you search in the UI by typing into the Search field in the top-right corner, this just queries that API with whatever you typed into the Search box as the 'q' parameter.

View solution in original post

2 REPLIES 2

avatar
Expert Contributor

The 'q' parameter is free-form (though URL encoded since it's part of the URL) and is whatever text you are searching for. For instance, it could be the UUID of a Processor, a Property Name or value, etc. If you search in the UI by typing into the Search field in the top-right corner, this just queries that API with whatever you typed into the Search box as the 'q' parameter.

avatar

Thanks Mark, so this is a quick way to search for 'expected' components and get an actual ID handle to work with them next. My use case is programmatic flow control through an API.