You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 21, 2024. It is now read-only.
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).
The text was updated successfully, but these errors were encountered:
The
GET /projects/{id}/events
endpoint supports a path query parameter calledtype_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"})
orclient.Projects.ListEvents(project_id, packngo.SearchOpts{QuerySuffix:"&type_in=devices"})
add
type_in
to SearchOptsclient.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).
The text was updated successfully, but these errors were encountered: