Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Research updating some fields to use APIObject type instead of full objects #279

Open
theckman opened this issue Feb 20, 2021 · 3 comments
Milestone

Comments

@theckman
Copy link
Collaborator

theckman commented Feb 20, 2021

There are some PagerDuty REST API endpoints that return API object references instead of the full objects for specific keys, to avoid sending massive amounts of (potentially unused) JSON across the wire.

Refer to this comment on a PR where a change was required to use APIObject instead, because it was the shape expected by the PagerDuty API: #273 (comment).

The reason I think we should investigate changing this, is because per our documentation some users may expect to see a full object sent back (see #250). This would be a v2.0.0 change.

@theckman
Copy link
Collaborator Author

Another example:

Alerts []IncidentAlert `json:"alerts,omitempty"`

@theckman
Copy link
Collaborator Author

theckman commented Nov 6, 2021

FirstTriggerLogEntry FirstTriggerLogEntry `json:"first_trigger_log_entry,omitempty"`

go-pagerduty/incident.go

Lines 60 to 64 in da97010

// FirstTriggerLogEntry is the first LogEntry
type FirstTriggerLogEntry struct {
CommonLogEntryField
Incident APIObject `json:"incident,omitempty"`
}

https://developer.pagerduty.com/api-reference/b3A6Mjc0ODE0MQ-get-an-incident

@theckman
Copy link
Collaborator Author

theckman commented Jan 16, 2022

go-pagerduty/on_call.go

Lines 11 to 13 in 77a73c9

User User `json:"user,omitempty"`
Schedule Schedule `json:"schedule,omitempty"`
EscalationPolicy EscalationPolicy `json:"escalation_policy,omitempty"`

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

No branches or pull requests

1 participant