Support Questions
Find answers, ask questions, and share your expertise
Alert: Please see the Cloudera blog for information on the Cloudera Response to CVE-2021-4428

Apache nifi web UI vs Programmatic

New Contributor

Hi All,

I am new Apache Nifi and little confuse about the way of using it.
I mean either i go by Apache Nifi web UI or should I configured it programmatic.

So I just wanted to know that which are the differences it has with the way of using.

The points I collected was something like if I use web UI than it would miss git support and cannot schedule job easily

But I think I may be wrong or I may missed something.

So can someone help to find the exact difference Or Does it has any functionality/feature difference Or Is it the case that I can achieve all functionality in both ways.



Master Guru
@Chintan Visani

Everything you can do directly from the NiFi UI can be done programmatically through the NiFi rest-api as well. There are no hidden capabilities that the rest-api exposes.


NiFi processors are the primary components which facilitates the movement and manipulation of data in the form of FlowFiles through NiFi. These components are individually configured and scheduled. Scheduling of a component supports a timer driven run schedule (either interval based or cron based) once a component has been started. What the rest-api allows you to do is programmatically start and stop these components in run once type scenarios via custom coded rest-api calls.


Either way all functionality exists via UI or rest-api. It is just a matter of preference how users prefer to interact with the NiFi endpoints.


Thank you,



If you found this answer addressed your question, please take a moment to login in and click the "ACCEPT" link.

Maybe I should make a new question for this, but in my organization I have alot of people asking me if they can start/stop their processors via the rest API. Of course they can, but I view that as an antipattern. Once you have things modifying your flow out-of-bands, your nifi flow is no longer the only place where logic is stored. Also mass start/stop of a process group suddenly becomes dangerous since some processors were maybe intended to be stopped. On a tiny single-purpose nifi instance this is probably not a problem, but on a large multi-tenant environment it can be.

You can get run-once or adhoc functionality by singalling your flow to start with a in-band semaphore file or message or something like that. You can get scheduling through processor settings. You can get appropriate throttling of flows during downstream failures by sizing your queues appropriately. In my mind there is no reason to use out-of-bands rest api start/stop.

Master Guru

@David Miller

Any changes you make via the rest api or directly via the UI are stored within NiFi and those changes are tracked via flow configuration history. But understandably supporting both methods corporately has its ups and down since user may start/stop/modify/etc components via UI that a script may then revert.
Mass start/stop actions as you mentioned can be less the ideal as well. Such an action may leave FlowFiles queued and un processed between these stopped components. I encourage that start/stop actions are limited to specific components (primarily those responsible for ingesting FlowFiles). This allows other processors within the "body" of a dataflow to continue processing as need all the time the data already ingested.