Skip to content

Instantly share code, notes, and snippets.

@steverice
Last active October 24, 2016 15:46
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save steverice/2f939ec894dfadc749bd1ac4b74c3d13 to your computer and use it in GitHub Desktop.
Save steverice/2f939ec894dfadc749bd1ac4b74c3d13 to your computer and use it in GitHub Desktop.
An example of an API decision made based on usage

An example of a relationship is Notification Rules, whose primary meaning is as a link between a user and a contact method. No individual notification rule has a unique, name-worthy meaning, and so they are handled (read and written) only as a collection. There is no compelling reason to update a single notification rule in place rather than replace the entire object with a new one. While this might seem like a significant loss of functionality, data shows that a trivially small number of clients outside of the PagerDuty web app are using it:

  • over the last 30 days, only 11 requests were made to PUT notification_rules/id using non-cookie authentication, and all by the subdomain redacted. While the mobile team experimented with it in the latest "Edit Notification Rules" update in 3.6, they've confirmed that that endpoint isn't being used.

Similarly, the escalation rules relationship sees little in-place use:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment