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 [email protected] or file a JIRA ticket
with INFRA.
---
