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

Cost efficient mappings to underlying APIs #325

joshco opened this Issue Jan 22, 2019 · 2 comments


None yet
1 participant
Copy link

joshco commented Jan 22, 2019


When integration systems with OSDI, one must consider cost-efficiency. As donor driven efforts, campaigns and non-profits, especially those serving smaller minorities and marginalized communities, limited funds are available and expenditures must be prioritized. To do so, it must be possible to align the granularity of OSDI API calls to the necessary underlying functions, while avoiding unnecessary API calls. There are multiple ways to approach this, comments/suggestions/feedback welcome.


Some vendors place limits or caps on usage, such as N/per day of free API calls, and any overages cost money. The price can be significant, such as 0.01 (a penny) per API call. An example scenario of misalignment is mapping OSDI calls like Person Signup Helper to underlying proprietary API calls for inserting a person into a system, applying tags or activist codes, and adding that person to lists or groups, which may be independent calls.

In this situation, given a cost of a penny per API call, the above scenario would cost at least 4 pennies. For that cost, a campaign could send more than 5 an sms message, or run an entire Amazon EC2 small instance for 2 hours, so trade-off decisions may be significant.


When an integration is performing the above scenario, it can be optimized, for example when updating a person that has previously been created, to avoid adding tags or groups that have previously been added, or choose not to request the representation (eg the response to a GET on the person) if it already has it.

OSDI has granular functions that can be smartly used to accomplish this optimization, except for avoiding returning the representation in the HTTP response.

Potential ideas for how to accomplish this could be:

  1. Add some kind of control attributes to PUT, POST, and helpers indicating that the client does not need the response to be included
  2. Define alternative operations that are defined which do not return the response. For helpers, this is relatively straightforward by creating new helpers. However, for PUT, POST, the semantics are defined by the HTTP method itself, and we cannot feasibly create new ones, so we'd need to look at changing the URL.,



This comment has been minimized.

Copy link
Contributor Author

joshco commented Jan 23, 2019

Based on committee discussion, current consensus is to define a control attribute to be included in requests to signal to the server, or a proxy translating to a proprietary API, that it can skip returning the response.
Pull request to follow


OSDI-API-Token:[your api key here]

   "osdi:control": {
      "return_response": false  /* default is true if not specified */
    "identifiers": [
    "family_name": "Edwin",
    "given_name": "Labadie",
    "additional_name": "Marques",
    "origin_system": "OpenSupporter",

@joshco joshco referenced this issue Jan 29, 2019


WIP osdi:control #330


This comment has been minimized.

Copy link
Contributor Author

joshco commented Jan 29, 2019

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