#ICYDK: Is providing an external streaming API enough of an application for most API providers? Each API we add to the Streamdata.io API Gallery, we create an account, add an application, and obtain keys that allow us to make API calls. We essentially become a consumer of each API we profile and add to the gallery. However, our goal isn’t to integrate a specific application or system with each API, we want to empower other application and system developers to do that. We’ve long seen our streaming service as something that each API provider should deliver on top of their API, but we are increasingly seeing that maybe it is an application that other API consumers can also put to work without the API provider always being an active part of the conversation.
The question is, is providing an external streaming API enough of an application to satisfy the terms of service for each API provider? Is augmenting an existing API with streaming, and event-driven capabilities seen as enough of an enhancement that API providers will support what we deliver? Or will they feel we are in violation of their terms of service and think its something they should be delivering on their own? It is a line we take seriously, and we’d prefer that API providers use our SaaS, or our on-premise to deliver our services to their customers. However, if we can’t get their attention, we feel it will be valid to act like we are just another application in their ecosystem, bringing value to the community. https://goo.gl/vvhMWz #DataIntegration #ML
Share this:
- Click to share on Facebook (Opens in new window)
- Click to share on Twitter (Opens in new window)
- Click to email a link to a friend (Opens in new window)
- Click to share on LinkedIn (Opens in new window)
- Click to share on Tumblr (Opens in new window)
- Click to share on Pinterest (Opens in new window)
- Click to share on Reddit (Opens in new window)