Liked I Started API Evangelist 10 Years Ago (

I don’t see APIs as good, nor bad, nor neutral anymore—they are as good or bad as whoever is wielding them, which with the lax security and ethics of most companies, it isn’t always the API provider inflicting the most damage to the ecosystem. APIs leave me very concerned most days. I am not very keen on building and owning production APIs in the current online world, but I am happy to stay in tune with how the machine works, help evangelize for some ethics and sanity in how we use them, and hopefully be somewhat of a voice of reason in the space, even if I am still doing a significant amount of selling of the concept, and perpetuating of the myths.

Liked Some Thoughts As We Go Through Our Internet Technology Awakening | Kin Lane (Kin Lane)

Don’t get me wrong, I am one of the new found awakened beings, not one of the ones that have been pushing back on things from the beginning. I have only begun to wake up to the damage being done about five years ago—-alongside some other awakening around gender and racism. However, I happened to be married to someone who has been critical since day one with her blog Hack Education, and happen to know other folks like Tressie McMillan Cottom (@ tressiemcphd), David Columbia (@dgolumbia), Bill Fitzgerald (@funnymonkey), Chris Gilliard (@hypervisible), Tim Maughan (@timmaughan), and others who have been highly critical all along. Even with these voices ringing in my ear over the last decade, I have struggled with clearly seeing a path forward and coming to terms with the damage I’ve incited as part of my work as the API Evangelist.

Liked API Evangelist | The Instructure LMS Data Points (API Evangelist)

This isn’t about shaming Instructure and it’s shareholders. This is about pointing out that we do not have any policies in place to prevent the exploitation of our schools and the students they serve. There is no approach to business or technology that will prevent the exploitation of student data. There is only a need to establish and strengthen federal and state policies that protect the privacy of students and their data, and minimizing the damage any platform can cause–no matter who owns it.

Bookmarked Intro To APIs: What Is An API? by Kin Lane (

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.

In his first official post as Chief Evangelist at Postman, Kin Lane (aka API Evangelist) provides a post starting at the beginning by defining what is meant by ‘API’:

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.

Along with posts from Ben Werdmuller, Tom Woodward, Alan Levine, as well as API Evangelist’s history of APIs, these posts provide a useful introduction to the world of APIs.

Liked What Is An Application? | API Evangelist (API Evangelist)

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.

Liked The Many Ways In Which APIs Are Taken Away | API Evangelist (API Evangelist)
  • Deprecation – APIs disappear regularly both communicated, and not so communicated, leaving consumers scratching their heads.
  • Disappear – Companies regularly disappear specific API endpoints acting like they were never there in the first place.
  • Acquisition – This is probably one of the most common ways in which high profile, successful APIs disappear.
  • Rate Limits – You can always rate limit away users make APIs inaccessible, or barely usable for users, essentially making it go away.
  • Error Rates – Inject elevated error rates either intentionally or unintentionally can make an API unusable to everyone or select audience.
  • Pricing Tiers – You can easily be priced out of access to an API making it something that acts just like deprecating for a specific group.
  • Versions – With rapid versioning, usually comes rapid deprecation of earlier versions, moving faster than some consumers can handle.
  • Enterprise – APIs moving from free or paid tier, into the magical enterprise, “call us” tier is a common ways in which APIs go away.
  • Dumb – The API should not have existed in the first place and some people just take a while to realize it, and then shut down the API.
Liked Why The Open Data Movement Has Not Delivered As Expected | API Evangelist (API Evangelist)

Open doesn’t mean democracy, it mostly means for business. This is the genius of the Internet evolution, is that it gets us all working in the service of opening things up for the “community”. Democratizing everything. Then once everything is on the table, companies grab what they want, and show very little interest in giving anything back to the movement. I know I have fallen for several waves of this ver the last decade.

Liked API Interoperability is a Myth | API Evangelist (API Evangelist)

Nobody, but us low-level delusional developers believe in API interoperability. The executives don’t give a shit about it. Unless it supports the latest myth-information campaign. In the long run, nobody wants their APIs to work together, we all just want EVERYONE to use OUR APIs!

Liked Doing The Hard Work To Define APIs (API Evangelist)

In my experience, once you really begin investing in the hard work to define the APIs you depend on, you begin to realize that you don’t need so many of them. That the number of API connections you depend on can actually begin to hurt you, which is something that can wildly grow if you aren’t in tune with what your API landscape consists of in your personal and professional worlds.

Liked What Does The Next Chapter Of Storytelling Look Like For API Evangelist? (API Evangelist)

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.

Liked Identifying The Different Types Of APIs (

To help me establish a handful of new buckets, I’m thinking more critically about the different types of API functionality I’m coming across, establishing seven new buckets:

  • General Data – You can get at data across the platform, users, and resources.
  • Relative Data – You can get at data that is relative to a user, company, or specific account.
  • Static Data – The data doesn’t change too often, and will always remain fairly constant.
  • Evolving Data – The data changes on a regular basis, providing a reason to come back often.
  • Historical Data – Provides access to historical data, going back an X number of. years.
  • Service – The API is offered as a service, or is provided to extend a specific service.
  • Algorithmic – The API provides some sort of algorithmic functionality like ML, or otherwise.
Bookmarked Living In A Post Facebook, Twitter, and Instagram API World (
Kin Lane discusses the current move to lock down social media APIs. He suggests that this could all have been avoided by having clearer guidelines in the beginning. Here I am reminded of Bill Fitzgerald and Kris Shaffer’s discussion of bots.
Liked Monetizing Your Device Location Data With LotaData (

In a world where our data is the new oil, I’m interested in any way that I can help level the playing field, and seeing how we can put more control back into the device owners hands. Allowing mobile phone, wearable, drone, automobile, and other connected device owners to aggregate and monetize their own data in a personal or professional capacity. Helping us all better understand the value of our own bits, and potentially generating some extra cash from its existence. I don’t think any of us are going to get rich doing this, but if we can put a little cash back in our own pockets, and limit the exploitation of our bits by other companies and device manufacturers, it might change the game to be a little more in our favor.

Liked Using Plain Language In Your API Paths (

There is no reason that your API paths shouldn’t be plain language, using common words. I’m not even talking about good RESTful resource design, I’m simply talking about looking at the URI for an API and being able to understand what it is because it used words we can understand. If you have trouble pausing, and stepping back, and thinking what some random 3rd party developer will interpret your API paths as, I recommend printing them out and sharing them with someone that isn’t on your team, and familiar with the resources you work with. Even if your APIs aren’t going to be public, someday you will be gone, and maybe your documentation isn’t up to date, and someone will have to reverse engineer what your API does. There is no reason your API should hide what it does, and not speak for itself, providing an intuitive, plain language description of the value it possesses.

Don’t be part of the problem in the future. Speak in plain language, and make your API paths speak for themselves.

Bookmarked API Is Not Just REST by Kin Lane (

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.

I read Kin’s work to continually develop my understanding of APIs. It would seem that they are having more and more of an impact on the way we work, yet so many people (I work with) have little understanding of what they are or how they work. These annotations are a useful starting point and capture a few key definitions.

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 Framework

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

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.

Bookmarked API Life Cycle Basics: Documentation (

API documentation should not be static. It should always be driven from OpenAPI, JSON Schema, and other pipeline artifacts. Documentation should be part of the CI/CD build process, and published as part of an API portal life cycle as mentioned above. API documentation should exist for ALL APIs that are deployed within an organization, and used to drive conversations across development as well as business groups–making sure the details of API design are always in as plain language as possible.

Kin Lane as the API Evangelist on the importance of documentation, this is a part of his work on API Basics
Bookmarked White, Male, And Convincing Myself I Am Doing Good With Technology (

Technology is a trip. Web technology is a delusion-ally virtual trip. It really seems to have many of us by the balls (pun intended), and working us like a puppet. I still perform this act on a daily basis via API Evangelist. Why? Because it makes me money! Of course, I’m always working to minimize the bullshit. Something I’m continuing to do by eliminating the mission driven rhetoric, but I just can’t quit API Evangelist. I’ve assumed this persona, and can’t seem to shake it. As I keep working to understand the beast I’ve created, I will continue to tell the story here on the blog.

Kin Lane reflects on the addictive nature of technology and the way in which he has convinced himself over time that he is actually doing good. This touches on the some of the ideas around ‘automating inequality’.