Subscribe to our Blog

×
Kin Lane
By Kin Lane Services, World of APIs June 2, 2016

The relationship between API provider and consumer is a fragile one. As an API provider, I am offering up my valuable digital asset, data, content, and digital resources.

I would like you to take this Application Programming Interface or SDK I have built, and put it in your business systems and applications. As an API consumer, I’m given access to valuable business API assets, which I’m expected use in a respectful way which is always in alignment with a provider’s terms of service — an environment where so much can go wrong, and does, each day.

I watch companies take a wide range of tones when it comes to setting the stage for this relationship. Some companies are super protective of their valuable content (like Marvel Comics), some are very communicative and inviting like Slack (inject your bot into us), where others wobble between a more open, the back to strict, like Twitter has done over the last couple years. In my opinion, it comes down to how you see your digital resources and your belief in intellectual property — when I say “you”, I mean you and your investors.

privacy

I try NOT to read all the patent notifications that come into my reader, as it depresses me, but every once in awhile, I have to revisit to help remind everyone, what an illness patents will be, when it comes to APIs working. This fragile relationship I speak of above, operates well, or not very well, depending on how loose, or how much friction exists at this layer. There are plenty of examples out there of APIs who do not do well when they restrict, or too heavily meter API consumers.

To help build an image in your mind, imagine the Twitter API, and all the apps that have been built on it. Okay, now add in Stripe for payments, Dropbox for storage, Instagram for Images, Facebook for Social, Amazon EC2 for computing, and YouTube for videos. Now, think about enforcing copyright on every API design, and patent licensing on each process involved. It will grind these billion-dollar revenue engines to a screeching halt. Nobody will build on these platforms if they have to bake your legal-heavy design and process into their business.

book-api

Modern web APIs are balanced between the technical, business, and politics of how data, content, and algorithms are exchanged. Simple, ubiquitous web technology is working on the technical side of things. Simple, pay as you go, utility-based, and tiered access is helping strike a balance on the business side of things. TOS, privacy, security, and transparency are the knobs and dials of the political side of things, let’s not willingly invite something so invasive, like patents into the API layer. Patent your algorithm, copyright your content, and license your data, but keep the API definition copyright free and your API process patent free.

In the “secure cloud storage distribution and aggregation” patent I’m reading this morning, it’s not the patent which offends me; it is the patent being so focused on the API being the thing that makes the patent. Patent how you index, search, and secure your file storage wizardry, but the API design and operations should NOT be a focal point of your patent. You want people to integrate with your “secure cloud storage distribution and aggregation” and bake the API design and process into their businesses. You want the cloud storage industry to speak your API. Don’t lock it down. Otherwise, API consumers will look elsewhere.

Maybe you’ll like these posts