[
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)
