{"API Evangelist"}

The API Journey Or What Is the Point of an API, By Tony Hirst (@psychemedia)

Tony Hirst (@psychemedia) wrote an interesting story about what I would consider the API journey, which he called, “What’s The Point Of An API?”. I’m the first to call bullshit on the term API, which is more storytelling magic than it ever was technical, for me. In my opinion, the point of an API is rarely ever the actual technical implementation—sorry devs. ;-( The point of the API is the journey, for the API provider, and the API consumer (both dev and end-user).

The point of the API is about the API provider reducing friction, when it comes to understanding, and put to work, valuable digital assets from data, content, to more programmatic, algorithmic elements like image filtering or video encoding, to more physical elements like a Nest thermostat, webcam access, or drone controls. An API does not automatically equal success, it take so much more than just launching an API to establish something that delivers value, and is sustainable--something that can be easier said than done, in todays volatile, digital environment.

The point of an API is about the API consumers having the freedom to discover, access, explore, and put to use valuable digital resources that they couldn’t deliver on their own, in new and interesting ways. Developers need to be part of a feedback loop with API providers that helps iterate APIs, and evolve APIs towards being more experience based beyond their resource oriented roots, and integrate them in meaningful ways into the systems, apps, and devices end-users depend on the most.

The point of an API is about empowering the end-user with applications that deliver value, all while opening up as much of the backend, and the pipes that are delivering valuable API driven resources, giving end-users a voice throughout the supply chain, using open formats like oAuth—bringing much needed transparency to the process. This isn’t just about tech, it is also about developing sustainable businesses built around applications that are truly deliver value, which along a way also protect the interests, security, and privacy of the end-user.

The API is not purely the technical elements, it is made up of the technical, business, and political building blocks, which includes the documentation, SDK, terms of service, pricing, and the many other essential aspects of API operations. APIs are definitely made up of the API projections into the users environment, and back-again, facilitating a real-time journey, that if done right, can benefit the API platform, developers who build upon it, and the end-users who ultimately define what the point of any API is.



Slowly Adding The People Layer To The API Evangelist Network

I'm adding a new layer to my monitoring of the API space, what I consider to be the people layer of the API Evangelist network--the actual people who are executing on much of what I talk about, across my research, and storytelling. This is all born out of the network of people I already talk to regularly, to get the stories, and details for the research that I publish regularly.

I have been tracking on many of the doers of the space for a while, behind the scenes, and this is just about exposing a select handful of individuals who can help you with some of the areas I discuss in my research and storytelling.

Up until now, my research has been about showcasing:

  • News
  • Companies
  • Tools

All I’m doing now is exposing some of the people who are doing interesting things as well, and are open to being contacted about their work, and discuss how you can potentially tap their expertise to help you achieve your API objectives. Over the next couple weeks, you will see me start listing individuals who are open to helping out in the core areas I research:

  • API Design
  • API Deployment
  • API Management
  • API Discovery
  • API Integration
  • API Evangelism
  • API Monetization
  • API Security

I already showcase companies in many of these areas, and track on the features, or building blocks employed to deliver products and services they offer, all I’m going to do now is provide more information on individuals who can help execute in these areas as well. Along the way you will also find me showcasing specific companies and tooling as well--API Evangelist partners like 3Scale, WSO2, and Restlet, but also other products I’m personally invested in like APIs.json, and the companies, and tools I use daily like Swagger, API Blueprint, APITools, API Science, and Runscope.

After five years of doing this, I’m trying to understand what scale looks like for API Evangelist. My objective is to keep funding my research, producing the short form (blog), and long form (guides, white papers, and blueprints), while keeping it all rooted in what the leading API providers, and ultimately the people behind them are doing on the ground. With this in mind, you will find more areas of my research, providing links to people actually doing these things in the field, and you will also hear more about the conversations I am having with these people as they execute their craft.

As always, if you, or your company is doing something interesting in these areas, let me know—if you are an individual looking to freelance in these ares, or build a consultancy delivering services in these areas, let me know. I can’t guarantee I’ll include you in my research, but if you are doing interesting things, you’ll stand out, and I’m sure I can find some way to showcase your work in a way that helps you, me, and the wider API space. Also, if you need help with a project in one of these areas, feel free to reach out, and I’ll do my best to point you in the right direction.



Postman Collections Will Take Your API Productivity To The Next Level

If you are an API developer, it is likely you have used Postman, the simple tool for building, testing, and documenting your APIs. I have Postman open as a Google Chrome App, which allows me to make API calls as I’m designing, developing, and integrating with the APIs across my world. Something which opens up the response and requests of API calls that I’m making, giving me more insight into how things are actually working (or not).

One of the key aspects of Postman, are the collections, which:

A collection lets you group individual requests together. These requests can be further organized into sub-collections/folders to completely mirror your API. Requests can also store variations and responses when saved in a collection. You can add metadata like name and description too so that all the information that a developer needs to use your API is available right where he(she) needs it. Collections are listed in the sidebar alphabetically. You can search through collection requests using the search form for quick access.

To me, Postman Collections are API discovery at the API transaction level. Allowing you to define a single unit of currency in the API economy, save, and organize them, and execute them at any point in your API lifecycle. Postman Collections measure not just an API transaction that happens, it is a measure of future transactions that can happen, complete with any relevant meta data that will be needed along the way.

Along with Swagger, and API Blueprint, I’m working to better understand how Postman Collections impact, and fuel the API lifecycle, including conversations with Abhinav Asthana (@a85), Founder and CEO of Postman, about their roadmap. Postman Collections are not just about defining, organizing, and executing your API calls in the Postman client as a solo API developer, they are also about collaborating with other key players involved throughout the API lifecycle.

I’m setting up my API Stack as Postman Collections, to help me understand how I can use the format to improve my API own API workflows. My goal is to ensure Postman works seamless with all stops along my own API and micro service lifecycle, from design to evangelism, and is plug and play as a machine readable element of APIs.json.



Ask The Stack When You Need API Support

I was profiling the video sharing API Dailymotion the other day, going through their developer area and profiling their API operations. One of the things I do as part of the profiling of any company, is checkout how they execute their support.

Dailymotion employs two very common building blocks for their platform support, including an API specific Twitter handle, and good ol fashion email—both pretty proven approaches. However Dailymotion also employs a third aspect to thier API support, by recommending you head over to Stack Overflow for some community support.

Using Stack Overflow in this way is not that original, I see numerous API providers doing this, the part I found interesting was their reference to getting Dailymotion API support via Stack Overflow as, "ask the stack!" I like that, I think it reflects what Stack Overflow is to the API developer community, and was an elegant way to send API developers off your site, to get the support they need.



We Need An Open Library Of The Most Common Utility API Implementations

I was spending time profiling APIs late last night while putting back a couple of IPAs. Yes this is what I do on a Friday night, you have a problem with that? Anyways, I was crafting Swagger definitions for the 7digital music APIs, and the I came across their territories API. "The Territories API serves data about countries that 7digital operates in, data about those counties, and a one or more languages with shop urls in each country”, something that I could see being pretty useful to developers when building music apps on top of the platform.

There has been numerous APIs I’ve developed in the past, where the need for some supporting, utility APIs, such as a list of states, zip codes, counties, or other resources was called for. Two layers to doing this: 1) Acknowledging the little things developers need goes a long way in building trust with them, letting them know you actually care, and get what they are facing 2) You want devs to achieve integration as quickly as possible, provide them with the little things that they will have to go hunt for, and possibly prevent them from achieving their objectives. — Reduce any friction possible!

I'd like to see an open source library of utility API design, complete with a variety of server side code, and data stores emerge, that help API providers deliver a more complete stacks of API resources. If you need a state / province API, or a language API, you could just grab one off the shelf and install it seamlessly into your API stack. This is just one of those little areas, that I think could be slowing the overall advancement of APis (just a wee bit), and with a little community effort, could really grease the wheels in API adoption, and fuel more meaningful integrations.