/incidents API improvements

[marcinc]

I'd like to propose a few improvements to the /incidents API:

• POST /incidents
  • Addition of optional componentID when new incident is created, for easier filtering later (see below)
• GET /incidents - add ability to filter / limit the list of incidents by any combination of the below:
  • componentID(optional) - filter incidents by component (could also support the list here)
  • status (optional) - list of statuses to return
  • since (optional) - a point in time (datetime) from which incidents are returned
  • limit (optional) - reduce number of items returned

[marcinc]

Also, option to order incidents by createdAt / updatedAt would be very useful.

[ks888]

So far the associations between components and incidents are not stored in the DB and so we need to reconsider the structure of the stored data.

To support the query parameters to filter incidents will be pretty simple (except componentID filtering) since the dynamo DB already supports a query operation. It's great if you have a chance to contribute the code.

Just curious, what is your use case of this feature?

[marcinc]

Will take a stab at adding the filtering in for existing data.

As for the componentID adding that in the Incident model would be pretty handy. Basic use case here would be that in some cases you might want to only quickly check whether there is a Resolved incident (or any other status for that matter) for a given component. So instead of fetching the entire list of incidents and iterating through (given the componentID is already known) you may simply fetch relevant entries only and optionally limit them further with extra limit, since and status (if needed).