Stacey emphasizes the very real problem of what’s an app to do when an API provider changes its terms of service? It’s not very pretty, and it’s unclear whether there is legal recourse.
But there’s another problem with traditional APIs. What happens when many apps want to share real-time data with many apps? Who has time to wire up so many API connections? How can any app in the ecosystem guarantee a quality of service with so many dependencies? How do app developers even find each other, let alone establish so many business and technical relationships?
One-to-many is pretty easy in that respect – we can all wire up to Facebook or Twitter. And one-to-one can also work. But many-to-many is a practical impossibility and that precludes meaningful data sharing between a large number of apps.
Think of the disadvantages faced by a real estate broker that doesn’t subscribe to Multiple Listings Service (MLS)? His inventory includes only his own listings and he gets no help selling those listing from other brokers. The same is currently true for every mobile app (or website) that’s trying to move inventory (whether coupons or pickup trucks).
The Flow is here to help. By inviting any number of app developers to share very granular sets of real-time data using a single set of XMPP/REST APIS, data sharing finally becomes easy and scalable with predictable quality of service.
Sets of real-time data (each a “flow”) can have many or few required and optional fields. Permissions can extend usage of a given flow to all apps (or end-users) or to defined number of apps. Individual flows can be fully public when created by a Flow librarian, or entirely private (or public) if created by an app developer or individual.
Check out Flow.net and sign up for our beta program if this all sounds interesting.
The way it is
What’s coming soon