Just a few thoughts -
It seems extremely ad-hoc. Why for policies and nothing else? What would
the "schema" of these "highlights" be? ("Highlights" is very vague; is
"usage metadata" a better term, given the sort of data you propose to
include in it?)
Is adding the data into the `policies` endpoint response the right place to
do this (as opposed to a separate endpoint, e.g. `/policies/highlights` or
better still `/highlights/policies`?
Above all else it seems an odd thing to add into the API itself, as opposed
to having Brooklyn record the data in some repository that you would query
- better to keep a separation of concerns between the API and the stats we
may want on its usage. Otherwise every time you need a new statistic you
have to update the API specification.
cheers
Geoff
On Thu, 7 Sep 2017 at 13:30 Graeme Miller <[email protected]> wrote:
> Hello,
>
> I'd like to make a change to the REST API for policies. As this is a REST
> API change I figured it would be best to flag it on the mailing list first
> in case anyone has any objections.
>
> It would be useful when consuming this API to be able to find out more
> information about the policy. Specifically, it would be useful to find out
> things like last action performed, last policy violation, last
> confirmation, what the triggers are etc.
>
> To do so, I plan to amend the REST API to include 'highlights' for a
> policy. Highlights are a map of a name to a tuple of information including
> description, time and task.
>
> Essentially this endpoint:
> "GET /applications/{application}/entities/{entity}/policies"
> Will now include this:
> [{
> ...
> "highlights": {
> "Last Confirmation": {
> "description": "sdjnfvsdjvfdjsng",
> "time": 12345689,
> "taskId": 1345
> },
> ...
> }
> }]
>
> Please shout if you have any problems with this, otherwise I'll submit a PR
> shortly with this change.
>
> Regards,
> Graeme Miller
>
