Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Cost efficient mappings to underlying APIs #325
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:
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.