metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From merrimanr <...@git.apache.org>
Subject [GitHub] incubator-metron issue #316: METRON-503: Metron REST API
Date Thu, 19 Jan 2017 17:43:14 GMT
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message