[jira] [Commented] (METRON-503) Metron REST API

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/METRON-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15801365#comment-15801365 ] 

ASF GitHub Bot commented on METRON-503:
---------------------------------------

Github user jjmeyer0 commented on the issue:

    https://github.com/apache/incubator-metron/pull/316
  
    
    **Project Structure:**
    
    Personally I think the module, `metron-interface`, should be split up into more modules. I think there should be `metron-rest` and `metron-rest-client`. The idea would be to move the models into the client module. Specifically the models returned by the endpoints and are used when making requests. I personally like to to do this because it allows a user to use the client without having to bring a ton of dependencies onto their classpath. This is assuming there will eventually be a client module. Does this make sense? Think it is worth doing now?
    
    **Response Behavior:**
    
    I think we should also decide how Metron's APIs handle errors. In the past I have defined an error response type that was used by all endpoints. It could potentially look something like:
    
    {
      "responseCode" : 404, 
      "message" : "Could not find parser config.", 
      'fullMessage" : "Could not find parser config with the name: [some name]"
    }
    
    Also, I personally do not like to throw exceptions of type `Exception`. I think we could do a couple things. We could create a MetronRestException that gets mapped to an error response. We could also have the service layer use an `Either` type which would either return the response entity or a set of error responses. Do you all think this is worth talking about now? I think this is always one of those things that's tough to decide, but should be standard across the API.
    
    **API Documentation:**
    
    I think it is worth documenting all the different response types for each endpoint. For example, the endpoint `/api/v1/sensorParserConfigHistory` only describes the response for a 200 code, but there is also a 404. This can be done by using Swagger's `ApiResponses` annotation.
    
    **API Structure:**
    
    As for API structure there were a few that I thought could potentially be changed. Below are a few examples. To me it may make sense at some point to have a sensor endpoint. IMO breaking it up as I did below groups them a bit more nicely (isn't an exhaustive list). What do you think? 
    
    /api/v1/globalConfig -> /api/v1/global/config
    /api/v1/sensorEnrichmentConfig -> /api/v1/sensor/enrichment/config
    /api/v1/sensorParserConfig -> /api/v1/sensor/parser/config
    /api/v1/sensorParserConfigHistory -> /api/v1/sensor/parser/config/history



> Metron REST API
> ---------------
>
>                 Key: METRON-503
>                 URL: https://issues.apache.org/jira/browse/METRON-503
>             Project: Metron
>          Issue Type: New Feature
>            Reporter: Ryan Merriman
>            Assignee: Ryan Merriman
>         Attachments: Metron REST API.docx
>
>
> As discussed on the dev list ([DISCUSS] Metron REST API Requirements), this Jira includes adding a REST API to Metron.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)