Skip to content
This repository has been archived by the owner on Jun 21, 2024. It is now read-only.

support Project.ListEvents type_in field #255

Open
displague opened this issue Apr 2, 2021 · 0 comments
Open

support Project.ListEvents type_in field #255

displague opened this issue Apr 2, 2021 · 0 comments

Comments

@displague
Copy link
Contributor

displague commented Apr 2, 2021

The GET /projects/{id}/events endpoint supports a path query parameter called type_in.

This field can be seen in use on the Equinix Metal console when filtering events by resource type.

Packngo does not offer a way to provide this value.

Some possibilities:

  • ignore the field, defer to resource specific event methods
    client.Devices.ListEvents(), client.Users.ListEvents(), ...

  • add the field as an extra ListEvents argument
    client.Projects.ListEvents(project_id, type_in, searchOpts)

  • provide a generic map field in ListOptions for additional (unknown) query parameters
    client.Projects.ListEvents(project_id, packngo.SearchOpts{Query:map[string]interface{"type_in":"devices"}) or
    client.Projects.ListEvents(project_id, packngo.SearchOpts{QuerySuffix:"&type_in=devices"})

  • add type_in to SearchOpts
    client.Projects.ListEvents(project_id, packngo.SearchOpts{TypeIn:"devices"}

    This allows SearchOpts to act as a grab-bag of documented limited use fields. I would avoid this unless type_in is commonly used or there are other one-off query params like type_in to include in SearchOpts. By assembling these fields in SearchOpts, we are giving up some of our strict type checking and permitted parameter enforcement.

I'd like to understand how common this parameter is or how many other one-off path parameters exist before proceeding. We can look at the api-docs path parameters to determine this (assuming the one-offs are included).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant