In the API economy everything is a problem that needs solving with an API. Need to get access to your accounting information? Use an API! Want your car to be more fuel efficient? Use an API! Want to water your house plants while away? Get an API! If there isn’t a real problem there, make one up, and create an API for it. Repeat until you find a problem, and a solution that will generate enough revenue to keep the lights on, and investors showing up at your door. APIs are behind almost every technosolutionism fantasy of the Internet age—both good and bad.
I am glad I didn’t go all in with Medium. I may have gotten more page views at the peak, but I think over time the long tail will be greater within my own domain. I am also feeling the same thing about Google lately. I used to cater to the SEO games, but after a couple of algorithm changes I haven’t been able to keep up, and my numbers are half of what they used to be. I find my time is better spend focusing on learning about the interesting things across the API sector, and writing a steady stream of stories, than it is tweaking the knobs and dials of the SEO beast. Google has become an ad engine, and I’m not in the business of generating revenue from ads, so it really doesn’t make sense for me to be playing that game full time.
I went into this last decade as a believer and came out the other end a cautious skeptic. This is a difficult place to find yourself in as an evangelist for a ubiquitous technology. It isn’t that I don’t believe in the power of technology anymore, it is just that the potential for abuse and explication within human hands is just too great to ignore anymore. After watching the Twitter and Facebook APIs fuck with our world so heavily in the last decade I am left questioning if I should be doing this at all. APIs aren’t good, bad, or even neutral. APIs are purely a reflection of their creators and operators. In the last decade APIs are being used for more harm than they are good, and the favorite tool for inflicting a lot of mediocre unsecured technology that doesn’t really care about the humans they are purportedly serving.
APIs are not a specific service or tool from a company, they are just like the web, but instead of getting HTML back with each request, you get JSON, XML, and CSV – providing structured, machine-readable information that can be used by other systems and within other applications with very little assistance from a human.
APIs are how data is exchanged, content is published, media is consumed, and algorithms are applied across the web today. APIs are how you access your social data, your photos, your accounting information, and much, much more.
I wanted to take a moment to understand what some of the surplus data that is generated from me just reading my RSS feeds for about an hour in my Feedly web application:
- Subscribe To – Every time I subscribe to an RSS feed, this information is added to my profile use later.
- How Long – How much time I put into cultivating feeds is a default part of surplus data being generated.
- Click and Read – Everything I click on and read adds a layer of behavioral surplus to be extracted.
- Tag and Organize – Everything I tag and organize shares my approach to taxonomy and understanding.
- Share With Others – The tags I turn into feeds and share continue painting a picture of what matters.
When you take these behavioral data points and multiply them by a couple thousand feeds, and hundreds of thousands of individual blog posts, GitHub updates, and Tweets that I subscribe to via my Feedly, it can paint a pretty relevant, real-time portrait of what Kin Lane is thinking about.
My view of what an application is stems from a decade of studying the least visible, and least tangible aspect of an application, its programming interface. When talking to people about applications, the first question I ask folks is usually, “do you know what an API is”? If someone is API savvy I will move to asking, “when it comes to application programming interface (API), who or what is being programmed? Is it the platform? The application? Or, is it the end-user of the applications?” I’ve spent a decade thinking about this question, playing it over and over in my end, never quite being satisfied with what I find. Honestly, the more I scratch, the more concerned I get, and the more I’m unsure of exactly what an “application” is, and precisely who are what is actually being programmed.
Audrey said something profound the other day which stuck with me. As we were talking about data and data ownership, she stated that, “I do not own me”—-pushing back on a common narrative around data ownership. Highlighting that conversations around the ownership of data are merely a dispossession vehicle for getting us to buy into concepts that you can own people. Muddying the water, and ultimately helping reducing humans to transactions. A photo taken by me or of me is not owned by me. It is me. There is no ownership of my physical or digital self. There is only me. I do not care if you’ve managed to digitally reduce a piece of me to a transaction, it is still me.
In my mind, the web will end up being just like automobiles. Everywhere. Dominating our life. Believing we can’t live without. While also polluting, destroying our environment, health, impacting our physical lives, but yet we will keep doubling down. Everyone keeps declaring that Internet technology is inevitable and will just keep marching forward, with endless innovations just off on the horizon. Perpetually looking forward, rather than ever pausing for a moment to look at the state of things. And, like commuters isolated I our automobiles, we will never truly acknowledge just how shitty this technology has actually made our lives, and refuse to ever accept there is any other to live.
I have separate but overlapping concerns when it comes to each of layers of schema in place across major tech providers. I have concerns about what is disclosed to users, as well as what is openly made available to 3rd party developers. But, I have the most concern about the portions of the schema that never see the light of day. The portions that us end-users have no idea exists, even though it is all data about us. The bits of our digital self that tech companies view as commodities, and actively use in products, and sometimes make accessible to partners, but refuse to ever tell us about, let alone give us a voice over what gets collected, and who has access to it. This is the schema that keeps me up at night. I feel like 95% of it will be harmless, and act more as an annoyance, than anything particularly troubling. However, it is the 5% of the schema that I can’t see, that I can’t correct, or that I do not have any voice over that could end up impacting my credit, my career, and have real world consequences in my physical life.
To help me make more progress I am breaking my efforts into three distinct phases:
- Healing – Cleaning up the mess I have created.
- Strengthening – Establishing the presence I want.
- Anchoring – Connect myself to things in the real world.
I feel like I have a lot more processing to do around the illness that digital photos introduce into my life. It isn’t just the number of photos, it is the many places where I put them. It is the performance I do with them online each day, across many web properties—mine, and other 3rd parties. It is unacceptable that I don’t take better care of digital self, curating, cleaning, organizing and being more thoughtful about the photos I produce, keep, or let disappear. It means for a healthier, saner, happier me, but it also reduces the vector for technology companies to get their hooks in me with their FREE storage, easy sharing, and other ways in which they monetize my digital self, and extract value from my daily behavioral exhaust.
There are many competing forces at play when it comes what technology that actually gets delivered, and it seems like most of us involved in the actual usage and delivery of these applications are in compliant denial regarding the wider forces at play. This was my first attempt at breaking down the reality of what technology ends up doing in our lives.
APIs are early sentinels. They are originally built as application development unit, but are quickly being given (cyber)military tasks. They lack dedicated offensive weaponry, but like a Sentinel, or maybe a Bobcat backhoe, they possess a number of potential attachments that can be weaponized pretty effectively.
In 2019, the API pioneers like SalesForce, Twitter, Facebook, Instagram, Twilio, SendGrid, Slack, and others are still relevant, but it feels like API storytelling is continuing it’s migration towards the enterprise. Stories of building an agile, scrappy startup using APIs isn’t as compelling as they used to be. They are being replaced by stories of existng enterprise groups become more innovative, agile, and competitive in a fast changing digital business landscape. The technology of APIs, the business of APIs, and the stories that matter around APIs have all been caught up in the tractor beam of the enterprise. In 2010, you did APIs if you were on the edge doing a startup, but by 2013 the enterprise began tuning into what is going on, by 2016 the enterprise responded with acquisitions, and by 2018 we are all selling and talking to the enterprise about APIs.
90% of what you are being told about AI, Blockchain, and automation right now isn’t truthful. It is only meant allocate space in your imagination, so that at the right time you can be sold something, and distracted while your data, privacy, and security can be exploited, or straight up swindled out from under you.
Much like the Internet’s inability to shake its military origins and use as a surveillance apparatus, I think the blockchain will never be able to shake its roots in a zero trust environment. Which requires a massive amount of faith in mathematics (not humans), and belief in the distributed nature of the web (which isn’t real).
For me, as an adult, I live on a new diet. I don’t fear the world around me. I know that most people are good, and work to expose those who wish to hurt us. I see the Russian propaganda machine for what it is. I see the web as a tool born of military origins, and being used to deliver misinformation. I question every fearful tale that I’m told, then venture out into the world to gather facts, learn from opposing perspectives, and push myself to learn each day. I wont stay isolated again, allowing my reality to be crafted by the fearful people around me. I’m in charge of crafting my own reality, and encouraging our children to do the same. I’m not letting their reality be dictated by people they grew up with–including me. Everyone should venture out into the world, and craft their own reality. One rooted in reality, and not just fear.
This is one of my talks from APIDays Paris 2018. Here is the abstract: The modern API toolbox includes a variety of standards and methodologies, which centers around REST, but also includes Hypermedia, GraphQL, real time streaming, event-driven architecture , and gRPC. API design has pushed beyond just basic access to data, and also can be about querying complex data structures, providing experience rich APIs, real-time data streams with Kafka and other standards, as well as also leveraging the latest algorithms and providing access to machine learning models. The biggest mistake any company, organization, or government agency can do is limit their API toolbox to be just about REST.
A Programmatic Interface
Application is about applying the digital resources made available via a programmatic interface.
Transport versus Influence
Looking back I wish we had spent more time thinking about how we were using the web as a transport, as well as the influence of industry and investment interests, but maybe it wasn’t possible as the web was still so new.
REST versus RPC
RESTafarians prefer that API providers properly define their approach, while many RPC providers could care less about labels, and are looking to just get the job done. Making XML and JSON RPC a very viable approach to doing APIs, something that still persists almost 20 years later.
REST is a philosophy, and much like microservices, provides us with a framework to think about how we put our API toolbox to work, but isn’t something that should blind us from the other tools we have within our reach.
CSV as a data format represents an anchor for the lowest common denominator for API access. As a developer, it won’t be the data format I personally will negotiate, but as a business user, it very well could mean the difference between using an API or not.
Our toolbox needs to still allow for us to provide, consume, validate, and transform XML.
API Query Language
There are trade offs with deciding to use an API query language, but in some situations it can make the development of clients much more efficient and agile, depending on who your audience is, and the resources you are looking to make available.
Webhooks are the 101 level of event-driven API architecture for API providers. It is where you get started trying to understand the meaningful events that are occurring via any platform.
Websub represents the many ways we can orchestrate our API implementations using a variety of content types, push and pull mechanisms, all leveraging web as the transport.
Server-sent events (SSE) is a technology where a browser receives automatic updates from a server via a sustained HTTP connection, which has been standardized as part of HTML5 by the W3C.
WebSocket is a different TCP protocol from HTTP, but is designed to work over HTTP ports 80 and 443 as well as to support HTTP proxies and intermediaries, making it compatible with the HTTP protocol.
As with other RPC approaches, gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types.
Kafka has moved out of the realm of HTTP, using a binary protocol over TCP, defining all APIs as request response message pairs, using its own messaging format. Each client initiates a socket connection and then writes a sequence of request messages and reads back the corresponding response message–no handshake is required on connection or disconnection.
One thing I’ve learned over the years while building my API toolbox is the importance of headers, and they are something that have regularly been not just about HTTP headers, but the more general usage of network networks.
Mixed Message Formats
In my world, there will always be a mixed of known and unknown message formats, something that I will always work to tame, as well as be increasingly apply machine learning models to help me identify, evolve, and make sense of–standardizing things in any way I possibly can.
So another step in our self care is to be gentle with ourselves. Depression is beating up on us already, and we don’t need to help it out. Give yourself permission to acknowledge that you’re feeling terrible (or bad, or whatever it is you are feeling), and then do a little thing, just one single thing, that you probably don’t feel like doing, and I PROMISE you it will help. Some of those things are:
- Take a shower.
- Eat a nutritious meal.
- Take a walk outside (even if it’s literally to the corner and back).
- Do something — throw a ball, play tug of war, give belly rubs — with a dog. Just about any activity with my dogs, even if it’s just a snuggle on the couch for a few minutes, helps me.
- Do five minutes of yoga stretching.
- Listen to a guided meditation and follow along as best as you can.
Finally, please trust me and know that this shitty, awful, overwhelming, terrible way you feel IS NOT FOREVER. It will get better. It always gets better. You are not alone in this fight, and you are OK.