Github user merrimanr commented on the issue: https://github.com/apache/incubator-metron/pull/316 The primary driver as I see it for a REST API is to facilitate building user interfaces for various interactions with Metron. At some point (I would argue now) we will want/need to evolve from just exposing functionality through a collection of command line utilities spread out across various hosts. That is not user friendly at all and anyone outside of our community of committers/contributors will have a steep learning curve. Most modern web development frameworks that I know of have all converged to REST and JSON standards for calling APIs. So to build a UI or encourage others in the community to build UIs, we need to expose functions in Metron through REST/JSON. Some functions are already exposed through a REST interface (the Storm REST API for example). But there are several gaps. A few that come to mind: - you cannot start/stop topologies through the Storm REST API - we are not managing sensor specific configs (parser, enrichment, indexing) with Ambari yet so the only way to do that is with the zk_load_configs.sh script - the only way to execute Stellar statements outside of topologies is with the Stellar REPL There are many more and there will no doubt be more that come up as the platform evolves. We need a middle-tier to fill in these gaps and grow our library of functions that users and developers can leverage. We've all agreed that managing sensor specific configs in Ambari has a lot of merit. When the time comes and that actually gets implemented, it's fairly trivial to either rip those endpoints out or change the underlying implementation. The REST API as it stands in this PR, makes the same exact calls as the zk_load_configs.sh script so the changes are likely minimal (they will have to be made to zk_load_configs.sh anyways). Removing the auditing endpoint in anticipation of moving configs to Ambari is perfectly reasonable. I am happy to update this PR with that change. There are probably further discussions we can have with respect to our REST strategy but right now we are missing a critical piece in our architecture. Even after we get the configs moved to Ambari we will still need this so I don't see any reason to hold it up. If any of this is unclear I am happy to explain further and provide additional documentation or diagrams.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---