RSS

API Support News

These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is testing their APIs, going beyond just monitoring and understand the details of each request and response.

Disaster API Rate Limit Considerations

This API operations consideration won’t apply to every API, but for APIs that provide essential resources in a time of need, I wanted to highlight an API rate limit cry for help that came across my desk this weekend. Our friend over at Pinboard alerted me to someone in Texas asking for some help in getting Google to increase the Google Maps API rate limits for an app they were depending on as Hurricane Harvey:

The app they depended on had ceased working and was showing a Google Maps API rate limit error, and they were trying to get the attention of Google to help increase usage limits. As Pinboard points out, it would be nice if Google had more direct support channels to make requests like this, but it would be also great if API providers were monitoring API usage, aware of applications serving geographic locations being impacted, and would relax API rate limiting on their own. There are many reasons API providers leverage their API management infrastructure to make rate limit exceptions and natural disasters seems like it should be top of the list.

I don’t think API providers are being malicious with rate limits in this area. I just think it is yet another area where technologists are blind to the way technology is making an impact (positive or negative) on the world around us. Staying in tune to the needs of applications that help people in their time of need seems like it will have to components, 1) knowing your applications (you should be doing this anyways) and identifying the ones that have a public service, and 2) staying in tune with natural and other disasters that are happening around the world. We see larger platforms like Facebook and Twitter rolling out permanent solutions to assist communities in their times of needs, and it seems like something that other smaller platforms should be tuning into as well.

Disaster support and considerations will be an area of API operations I’m going to consider adding into my research, and spending more time to identify best practices, and what platforms are doing to better serve communities in a time of need using APIs.


The Importance Of API Stories

I am an API storyteller before am an API architect, designer, or evangelist. My number one job is to tell stories about the API space. I make sure there is always (almost) 3-5 stories a day published to API Evangelist about what I’m seeing as I conduct my research on the sector, and thoughts I’m having while consulting and working on API projects. I’ve been telling stories like this for seven years, which has proven to me how much stories matter in the world of technology, and the worlds that it is impacting–which is pretty much everything right now.

Occasionally I get folks who like to criticize what I do, making sure I know that stories don’t matter. That nobody in the enterprise or startups care about stories. Results are what matter. Ohhhhh reeeaaaly. ;-) I hate to tell you, it is all stories. VC investment in startups is all about the story. The markets all operate on stories. Twitter. Facebook. LinkedIn. Medium. TechCrunch. It is all stories. The stories we tell ourselves. The stories we tell each other. The stories we believe. The stories we refuse to believe. It is all stories. Stories are important to everything.

The mythical story about Jeff Bezos’s mandate that all employees needed to use APIs internally is still 2-3% of my monthly traffic, down from 5-8% for the last couple of years, and it was written in 2012 (five years ago). I’ve seen this story on the home page of the GSA internal portal, and framed hanging on the wall in a bank in Amsterdam. Stories are important. Stories are still important when they aren’t true, or partially true, like the Amazon mythical tale is(n’t). Stories are how we make sense of all this abstract stuff, and turn it into relatable concepts that we can use within the constructs of our own worlds. Stories are how the cloud became a thing. Stories are why microservices and devops is becoming a thing. Stories are how GraphQL wants to be a thing.

For me, most importantly, telling stories is how I make sense of the world. If I can’t communicate something to you here on API Evangelist, it isn’t filed away in my mental filing cabinet. Telling stories is how I have made sense of the API space. If I can’t articulate a coherent story around API related technology, and it just doesn’t make sense to me, it probably won’t stick around in my storytelling, research, and consulting strategy. Stories are everything to me. If they aren’t to you, it’s probably because you are more on the receiving end of stories, and not really influencing those around you in your community, and workplace. Stories are important. Whether you want to admit it or not.


API Platform FAQ And QA Responsibility

The discussion around whether or not you should be hosting your own questions and answers (QA) and frequently asked questions (FAQ) for your API has continued, with many of the leading API pioneers asserting responsibility over the operations of these important API resources. Amazon noticed that answers about their platform on Quora and Stack Exchange were usually out of date and often just plain wrong, prompting them to launch their own QA solution.

I have written about using API providers using Stack Overflow for may years now. It the last few years I’ve had my readers push back on this for a variety of reasons, from the Stack Overflow community being primarily a white male bro-fest, to finding things being unreliable, out of date, and often a pretty hostile and unfriendly place for people to try and learn about APIs. I’d say that I still use Stack Overflow for about 40% of my querying of API and programming related subjects, but since I’m a white male who has been doing software for 30 years, I’m a little more resistant to the bro-fest. But, I get it, and hear what folks are saying, and get it is not always a suitable environment.

Going back and forth on this subject, I’m back in the camp where API providers should be investing in operating their own QA, FAQ, and support forums. It’s definitely requires a significant amount of investment, policing, and sometimes taking stances that are unpopular, but if you are in this for the long game, it will be worth it. After watching AWS for a decade, you can see how incorrect information about your API operations can really begin to become a liability, and you might want to keep a tighter grip on where your API consumers go look for their answers. An added bonus is that you also get to set the tone for the types of questions that get answered, and the inclusiveness that will exist across your FAQ, QA, and Support.

I really need to get my core API design guides like definitions, design, deployment, and management out the door, because I need to diving into areas like support, and gather all my thoughts regarding how API providers should be approaching this critical layer of operations. I feel like support is one of the most defining characteristics of sustainable API providers, right up there with communications I’d say. I don’t care how good your API is technically, if you don’t have a solid approach to supporting and communicating with your API community, I’m guessing you won’t be around very long, or if you do survive, your platform will be something savvy API consumers steer clear of.


The Plivo Support Portal And Knowledge Base

I’m always watching out for how existing API providers are shifting up their support strategies in their communities as part of my work. This means staying into tune with their communications, which includes processing their email newsletters and developer updates. Staying aware of what is actually working, and what is not working, based upon active API service providers who are finding ways to make it all work.

Plivo opted out to phase out direct emails at the end of the month, and pushing developers to use the Plivo support portal, and the ticketing system. The support portal provides a knowledge base which provides a base of self-service support before any developer actually uses the support ticketing system to:

  • Create, manage, respond to and check the status of your support ticket(s)
  • Select improved ticket categories for more efficient ticket routing and faster resolution
  • Receive resolution suggestions from our knowledge base before you submit a ticket to help decrease resolution time

Email only support isn’t always the most optimal way of handling support, and using a ticketing system definitely provides a nice trail to follow for both sides of the conversations. The central ticketing system also provides a nice source of content to feed into the self-service support knowledge base, keeping self-service support in sync with direct support activity.

I’m going to continue to track on which API providers offer a ticketing solution, as well as a knowledge base. I’m feeling like these are what I’m going to recommend to new API providers as what I consider to be default support building blocks that EVERY API platform should be starting with, covering the self-service and direct support requirements of a platform. I’m going to start pushing 1-3 support solutions like ZenDesk, also giving API providers some options when it comes to quickly delivering adequate support for their platforms.


Tweeting Out Your API Forum Conversations

It is a lot of work to keep the API evangelism drumbeat going each day on your blog, Twitter, and other social media channels you use for your API operations. Each Tweet, Facebook or LinkedIn Post is one possible signal that might reach existing developers, or possibly reach a potentially new API consumer–educating them about what your API does.

My friends over at the Oxford Dictionaries APIs are getting really good at this API evangelism song and dance, and one of the tactics in their toolbox is regularly Tweeting out relevant threads from their API forum. It is a great way to expose conversations that are going on within your API support forum, and help make other developers aware that these conversations are going on in a way that will also boost your overall SEO, making your API support operations more visible to the public.

Another benefit of sending out these regular API signals is that there is always the potential that I will write up what you are doing, and you’ll get the additional exposure of being on API Evangelist. When people ask me what is the #1 thing they can do to be more successful with evangelism for their API, it is always consistency. Regular, consistent drumbeats about what is going on with your platform, the problems it solves is always the best way to make sure your valuable API resources will be found and put to use in meaningful ways.


The Support Elements Of Your API Service Level Agreement

Zendesk gave me some valuable building blocks to add to both my API support and API service level agreement research, with their support SLA. This is why I keep an eye on not just how API providers are handling their support, but also how leading support software as a service API providers are setting the bar for how we do support.

The Zendesk support SLA provides us with some valuable information about setting a service level objective, developing support SLA workflow, dealing with a breach, and even some key performance indicators (KPIs) to help you measure success. I will be taking the bullet points from each area and adding to the overlap of my API support and service level research, and I’ll even begin flushing out my API breach research with its first handful of building blocks regarding how to handle a really bad situation.

I’m seeing an uptick in the number of SLAs with leading API providers, so it makes sense to start considering how other aspects of API operations should be reflected in our API service level agreements. How you support and communicate with your customers can be just as important as the technical bullets of your SLA. Most of the SLAs I’ve read in the API space focus on the technical, business, and legal considerations of integration, but Zendesk reminds us of the actual human elements of setting and meeting a specific level of service when it comes to API integration.


The Depth And Dimensions Of Monitoring API Operations

When I play with my Hitch service I am always left thinking about the many dimensions of API monitoring. When you talk about API monitoring in the tech sector conversations almost always start with the API providers and the technical details monitoring of individual APIs. Hopefully, these discussions also focus on API monitoring from the API consumers point of view, but I wanted to also shine a light on companies like Hitch who are adding an additional dimension from the API service provider view of things–which is closer to my vantage point as an analyst.

I am an advisor to Hitch because they are a different breed of API monitoring service, that isn’t just focused on the APIs. Hitch brings in the wider view of monitoring the entire operations of an API–if documentation changes, an SDK on Github, or update via Twitter, or a pricing change, you get alerted. As a developer I enjoy being made aware of what is going on across operations, keeping me in tune with not just the technical, but also the business and politics of API platform operations.

Another reason I like Hitch, and really the reason behind me writing this post, is that they are helping API providers think about the bigger picture of API monitoring. Helping them think deeply, as well as getting their shit together when it comes to regularly sending out the critical signals us API consumers are tuning into. When you are down in the trenches of operating an API at a large company, it is easy to get caught up in the internal vacuum, forgetting to properly communicate and support your community–Hitch helps keep this bubble from forming, assisting you in keeping an external focus on your community.

If you are just embarking on your API journey I recommend tuning into API Evangelist first. ;-) However, if you are unsure of how to properly communicate and support your community I recommend you talk to the Hitch team. They’ll help get you up to speed on the best practices when it comes to API operations, and understand how to send the right signals to your community–something that will make or break your API efforts, so please don’t ignore it.

Disclosure: I am an advisor for Hitch, and they are my friends.


Heavier Investment In API Training Will Be Necessary

</a>

I was learning about the virtual classes that Github are offering, as I was working on some basic API curriculum for some of my clients, and I was reminded of how important training and education is when it comes to technological adoption. Not everyone learns the same way, and not everyone is an autodidact, and providing training around any technology, platform, or service your company, institution, or government agency is adopting is important.

If you look at the historic spending of leading API companies like Apigee, you’ll see a large chunk of the budget going to educating and bringing would be or existing clients up to speed with the technology in play. Training and education will be a significant portion of each of the trends you see in play like DevOps, Microservices, and Serverless. A core aspect of all of these movements hinges on unwinding legacy technical debt and moving often large groups of people forward with a new way of doing things–if education isn’t a significant portion of your strategy, you will fail.

If you see any interesting API training out there on LinkedIn (Lynda), or on the open web, please let me know, I’d like to start curating more resources for people to use. I am also working with groups to develop their own internal API training and curriculum to match not just the wider API space, but also what is going on internally within an organization. In coming months I will also be going through each of my research areas that might help API providers think about how they are going to tackle API education and help my readers understand that a heavier investment in API training will be necessary to steer the ship where you want it to go.


Google Support Buttons

I talked about the gap between developer relations and support at Google, something that Sam Ramji (@sramji) has acknowledged is being worked on. Support for a single API can be a lot of work and is something that is exponentially harder with each API and developer to add to your operations, and after looking through 75 of the Google APIs this weekend, you see evidence that Google is working on it.

While there are many Google APIs that still have sub-standard support for their APIs, when you look at Google Sheets you start seeing evidence of their evolved approach to support, with a consistent set of buttons that tackle many of the common areas of API support. For general questions, Google provides two buttons linked to StackOverflow:

The search just drops you into Stack Overflow, with the tag "google sheets api", and the ask a new question drops you into the Stack Overflow submit new question form. For bug reporting, they provide a similar set of buttons:

The search and report bug buttons drop you into the Google Code issues page for Google Sheets, leveraging the issues management for the Gooogle Code repository--something that can just as easily be done with Github issues. Then lastly, they provide a third set of buttons when you are looking to submit a feature:

Even though there is a typo on the first button, they also leverage Google Code issue management to handle all feature requests. Obviously working to centralize bug and feature reporting, and support management using Google Code--something I do across all my API projects using Github organizations, repositories, and their issue management. I'm guessing Google Support is tapping into Google Code to tackle support across projects at scale.

These support buttons may seem trivial, but they represent a more consistent approach by the API giant to be consistent in how they approach support across their API offerings--something that can go a long way in my experience. It gives your API consumers a familiar and intuitive way to ask questions, submit bugs, and suggest new features. Equally as important, I'm hoping it is also giving Google a consistent way to tackle support for their APIs in a meaningful way, that meets the needs of their API consumers.


The Relationship Between Dev Relations And Support

I saw an interesting chasm emerge while at a Google Community Summit this last week, while I heard their support team talk, as well as their developer relations team discuss what they were up to. During the discussion, one of the companies presents discussed how their overall experience with the developer relations team has been amazing, their experience with support has widely been a pretty bad experience--revealing a potential gap between the two teams.

This is a pretty common gap I've seen with many other API platforms. The developer relations team is all about getting the word out, and encouraging platform usage and support teams are there to be the front line for support and being the buffer between integration, and platform engineering teams. I've been the person in the role as the evangelist when there is a bug in an API, and I'm at the mercy of an already overloaded engineering team, and QA staff, before anything gets resolved--this is a difficult position to be in.

How wide this chasm becomes ultimately depends on how much of a priority the API is for an engineering team, and how overloaded they are. I've worked on projects where this chasm is pretty wide, taking days, even weeks to get bugs fixed. I'm guessing this is something a more DevOps focused approach to the API life cycle might help with, where an API developer relations and support team have more access to making changes and fixing bugs--something that has to be pretty difficult to deal with at Google scale.

Anyways, I thought the potential chasm between developer relations and support was worthy enough to discuss and include in my research. It is something we all should be considering no matter how big or small our operations are. There is no quicker way to kill the morale of your API developer relations and support teams by allowing a canyon like this to persist. What challenges have you experienced when it comes to getting support from your API provider? Or inversely, what challenges have you faced supporting your APIs or executing on your developer outreach strategy? I'm curious if other folks are feeling this same pain.


All The Right Channel Icons In Support Of Your API Platform

I look at a lot of websites for companies who are providing APIs and selling services to the API space. When I find a new company, I can spend upwards of 10 minutes looking for all the relevant information I need to connect. Elements like where their Twitter and Github accounts are. These are all the key channels I am looking for so that I can better understand what a company does and stay in tune with any activity, but they are also the same channels that developers will be looking for so that they can stay in tune a platform as well.

I spend a great deal of time looking for these channels, so I'm always happy when I find companies who provide a near complete set of icons for all the channels that matter. Restlet, the API design, deployment, management,and testing platform has a nice example of this in action, providing the following channels:

  • Facebook
  • Twitter
  • Google+
  • LinkedIn
  • Vimeo
  • Slideshare
  • Github
  • Stack Overflow
  • Email

All of these channels are available as orderly icons in the footer of their site. Making my job easier, and I'm sure making it easier for other would be API developers. They also provide an email newsletter signup along with the set of icons. While this provides me with a nice set of channels to tune into, more than I usually find, I would still like to have a blog and atom feed icons, as well as maybe an AngelList or Crunchbase, so that i can peak behind the business curtain a little.

I know. I know. I am demanding, and never happy. I am just trying to provide an easy checklist for companies looking to do interesting things APIs of the common channels they should consider offering. You should only offer up channels that you can keep active, but I recommend that you think about offering up as many of these as you possibly can manage. No matter which ones you choose, make sure you organize them all together, in the header and footer of your website, so nobody has to go looking for them.


Every Government Agency Should Have An FAQ API Like The DOL

I wrote about my feelings that all government agencies should have a forms API like the Department of Labor (DOL), and I wanted to separately showcase their FAQ API, and say same thing--ALL government agencies should have a frequently asked question (FAQ) API. Think about the websites and mobile applications that would benefit from ALL government agencies at the federal, state, and local level having frequently asked questions available in this way--it would be huge. 

In a perfect world, like any good API provider, government agencies should also use their FAQ API to run their website(s), mobile, and internal systems--this way the results are always fresh, up to date, and answering the relevant questions (hopefully). I get folks in government questioning the opening up of sensitive information via APIs, but making FAQs available in a machine readable way, via the web, just makes sense in a digital world.

Like the forms API, I will be looking across other government agencies for any FAQ APIs. I will be crafting an OpenAPI Spec for the DOL FAQ API (man that is a lot of acronyms). I will take any other FAQ APIs that I find and consider any additional parameters, and definitions I might want to include in a common FAQ API definition for government agencies. This is another area that should have not just a common open API and underlying schemas defined, but also a wealth of server and client side code--so any government agency can immediately put it to work in any environment.


The Month At A Glance, Road Map, Support, And The Recent Posts For Your API Platform

I was playing with Microsoft's API Catalog, a tool to visualize and analyze the API overlap between standards specifications and type systems within browsers, and their footer caught my eye. I am always looking for quality examples of companies doing platform communications and support well, and I think their layout, and available building blocks in their footer, is worthy of showcasing.

For me, these numbers, and the available communication and support building blocks, send the right signals--that a platform is alive and active. These are the data points I tune into, to understand how well a platform is doing, or not doing. There are no absolutes when it comes to this type of monitoring, as anything can be gamed, but sign Github activity, road map evolution, and blog storytelling can provide a vital heartbeat for any healthy API platform. 


Managing The ClinicalTrials.gov Support, Feedback, And Roadmap Using Github

Each of the Adopta.Agency project runs as a Github repository, with the main project site running using Github Pages. There are many reasons I do this, but one of the primary ones is that it provides me with most of what I need to provide support for the project.

Jekyll running on Github pages gives me the ability to have a blog, and manage the pages for the project, which is central to support. Next I use Github Issues for everything else. If anyone needs to ask a question, make a contribution, or report a bug, they can do so using Github Issues for the repository

I even drive the project road map, and change log using Github Issues. If I tag something as roadmap, it shows up on the road map, and if I tag something as changelog, and it is a closed issue, it will show up on the change log--this is the feedback loop that will help me move the clinical trials API forward.


Breaking Out API Support Into A Separate Research Area

Supporting your community is not unique to the API space, but supporting API operations does have some unique needs, and approaches that are proven by leading platforms. Like other areas of my research, I'm pulling out API support into its own area, so I can start shining a light on successful patterns I find in the area of API support.

Two things pushed me to spin out this research area. One, I was tagging more blog posts, and other resources as support, and without a dedicated research area, this information would rarely float to the surface for me. Two, my partners over at Cloud Elements have an API hub dedicated to "Help Desk". While their aggregate API solution is targeting beyond the API community, it is API driven, and can also be applied to providing an aggregate support solution for API communities.

As with most of the areas of the API space, there are several dimensions to how APIs are being applied to support customers, and online communities. With my research, I will focus on tracking on approaches to community support for API providers, and API service providers. There will also be that layer of tracking on help desk and support platforms who employ APIs, as well as API aggregate and API interoperability solutions from leaders (and my partners) in the space like Cloud Elements.

You can visit my API support research via its Github repository, and I will try to make sure and continue linking to it from my API management research, where it was born out of.


Update 265 Pages, and 175 Links On My Network To Support Swagger to OADF Shift

I have written 265 separate posts, across the API Evangelist network about Swagger, in the last three years. To reflect the recent shift of Swagger into the Open API Initiative (OAI), and the specification being reborn as Open API Definition Format (OADF), I wanted to update all the stories I've told over the years, to help educate my readers of the evolution, and provide the most relevant links possible.

Using my Linkrot API, which helps me manage the links across my network of sites, I've identified all the pages with Swagger relevant links, and made sure they are updated to point at the most recent material. I've also added a banner to each of the 265 posts, helping educate readers who come across these posts, regarding the transition from Swagger to OADF, and help them understand where to find the latest information.

My network of sites is meant to be my workbench for the API space, and provide the latest information possible about what drives the API sector. It is important to me that the information is as accurate as possible, and my readers stay in tune with the shifts of the APIs space, and where they can find what they need to be successful.

In the end though, all of this is really just business. 


Using Existing Online Forums vs Developing Your Own To Support API Operations

As I tune into the fallout around the Reddit community, I think it is a good time to pull a story out of my notebook, that I began writing a month or two ago. These thoughts are born out of my post Ask The Stack When You Need API Support, where my friend Jeremiah Lee (@JeremiahLee) commented, disagreeing with my recommendation that API providers use Stack Exchange as part of operations. 

Jeremiah shares his story about how hostile Stack Overflow can be (I'll let you read his comment on your own), something that has been re-enforced many times along the way. While I still endorse Stack Overflow as a valuable building block for some APIs, I completely agree with Jeremiah about the overall community tone. While Stack Overflow is definitely a different beast, it suffers from some of the similar systemic illnesses, that Reddit does. I find some very valuable information on Stack Overflow, which I use regularly, but if you are looking to develop an API community, I can envision the community potentially working against you, in several ways.

It really depends on your API, and the target audience you are trying to reach. Sometimes, the male dominated, "gamified community of meritocracy, where established members have many rules and politics", as Jermiah says, is exactly who you should be engaging, but you really need get to know the personae of your ideal customers, and decide on your own. For API Evangelist, both my storytelling, and the APIs I provide, I've long felt Stack Overflow is not my target audience.

Similar to Reddit, Hacker News, and DZone, I get very little value from these communities. While I do find nuggets of information at these places, I do not post my stories, and engage in conversations there, because the hostility that can come from these channels I have found outweighs any value they might bring in traffic. I seek a much wider audience, than the individuals who often dominate these tech hangouts.

I encourage you to think deeply about who you want to reach with your APIs, and while building your own community in your own wiki, forum, or other solution, might take a lot of time and work, it gives you greater control over the tone your forum takes--which might make the difference in attracting the right developer and business audience you seek.


@Broadcom, I Am Going To Need Your Switches To Support Virtualized Containers So I Can Deploy My Own APIs Too

While processing the news today over at API.Report, I came across a story about Broadcom delivering an API for managing their latest network infrastructure. The intersection of Software Defined Networking (SDN) and Application Programming Interface (API) is something I’m paying closer attention to lately. Hmmm. SDN + API = Brand New Bullshit Acronym? Meh. Onward, I just can’t slow down to care--{"packet keep moving"}.

At the networking level, I’m hearing Broadcom making a classic API infrastructure argument, "With the OpenNSL software platform, Broadcom is publishing APIs that map Broadcom's Software Development Kit (SDK) to an open north bound interface, enabling the integration of new applications and the ability to optimize switch hardware platforms.”, with examples of what you could build including "network monitoring, load balancing, service chaining, workload optimization and traffic engineering."

This new API driven approach to networking is available in the Broadcom Tomahawk and Trident II switches, looking to build up a developer community who can help deliver networking solutions, with Broadcom interested in giving, "users the freedom to control their technology, share their designs and boost application innovation.” Everything Broadcom is up to is in alignment with other valid Internet of Things (IoT) efforts I’m seeing across not just the networking arena, but almost any other physical object being connected to the Internet in 2015.

I think what Broadcom is doing, is very forward leaning effort, and providing native API support at the device level is definitely how you support “innovation” around your networking infrastructure. To keep in sync with the leading edge of the current API evolution as I'm seeing it, I would also recommend adding virtualized container support at the device level. As a developer I am thankful for the APIs that you are exposing, allowing me to develop custom solutions using your hardware, but I need you to take it one level further--I need to be able to deploy my own APIs using Docker, as well as working with your APIs, all running on your infrastructure.

I need your devices to support not just the web and mobile apps I will build around your around your hardware, and the API surface area you are providing with the new Tomahawk and Trident II switches, I need to also plugin my own microservice stack, and the microservices that vendors will be delivering to me. I need the next generation of switches to be API driven, but I also need to guarantee it is exactly the stack I need to achieve my networking objectives.

That concludes my intrusion into your road-map. I appreciate you even entertaining my ideas. I cannot share much more details on what I intend to do with your new SDN & API driven goodness, but if you work with me to let me innovate on your virtual and physical API stack—I feel that you will be surprised with what what the overall community around your hardware will deliver.


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.


APIMATIC Code-Generation-as-a-Service Has Built-In Support For API Commons Manifest

The API savvy folks over at Apimatic are at it again, pushing forward the conversation around generating of software development kits, using machine readable API formats, and this time the doorway to your SDK is via the API Commons manifest.

I'm going to go ahead and use their own description, as it sums it well, no augmentation needed. Using the code generation API, you can generate SDKs for your API directly from your Github repository. 

Step 1: Describe you API using some format. You may choose from Swagger, RAML, APIBlueprint, IODocs, and Google Discovery formats. Automatic code generation makes use of information in your API description to generate method and classes names. Please be as expressive as possible by not leaving out any optional fields as applicable e.g., not leaving out types and schemas for your parameters and fields.

Step 2: Define meta information about your API using API Commons manifest format. You can generate your API Commons manifest using the API Commons Manifest generator. Be sure to enter all relevant information. Upload the generated manifest as a new file in the root directory of your Github repo by the name "api-commons- manifest.json". Be sure to have the correct name and location of this file.

Step 3: Open/Create a markdown file (README.md is a good candidate). Add the following markdown syntax to render an image link.

[![apimatic][apimatic-{platform-name}-image]][apimatic-{platform- name}-url]

[apimatic-{platform-name}-url]: https://apimatic.io/api/github/{account-name}/{repo-name}/{branch- name}?platform={platform-name}

[apimatic-{platform-name}-image]: https://apimatic.io/img/github/{platform-name}.svg

Replace the {platform-name} token with one of the following values: windows, android, ios
Replace the {account-name} token with the name of your url-encoded Github account name
Replace the {repo-name} token with the name of your url-encoded Github repository name
Replace the {branch-name} token with the name of your url-encoded Github branch name where the API Commons manifest file is present. 

To validate, open the following url after replacing tokens. This url should open the raw manifest file. https://raw.githubusercontent.com/{account-name}/{repo-name}/{branch- name}/api-commons-manifest.json

You can see an example here. Commit changes and navigate to your Markdown file in your browser. You will see apimatic widgets (image links), which you can click to generate SDKs for your API. To see an example, open this link to view the README.md file in raw text form.

The Apimatic team is owning the conversation when it comes to generation of full fledge SDKs for your APIs. I always hear folks talk about the limitations of auto-generation of client side code, but the Apimatic team is pushing the conversation forward with their persistent approach.


Why Would You Ever Give Students API Access To The Student Information System (SIS), And Let Them Build Un-Sanctioned Apps That We Will End Up Having To Support?

I went up to California State University Channel Islands the other day to talk APIs with their tech team, and I was happy to find at least one strong API skeptic on the team. API skeptics also give me material for stories, so I thoroughly enjoy coming across them, and telling these stories is how keep polishing my argument for the next API skeptic encounter at campus IT, at the higher educational institutions that I visit.

During the discussion I was posed several interesting questions, and one of them was: why would you ever give students API access to the Student Information System (SIS), and let them build un-sanctioned apps that we will end up have to support?

Family Educational Rights and Privacy Act (FERPA)
FERPA gives students the right to review, control disclosure, and request amendment of their education record. Increasingly this is going beyond just via a web interface, PDF, or printed copies. President Barack Obama mandated that all federal agencies begin providing information in machine readable formats, and many cities and states are putting it into law as well. A student should always have access to their data, and they should be able to choose to do this via campus applications, or be able to obtain a portable copy of their record for storage in a location of their choosing, or possible use within a 3rd party system of their choice—it's their data. Period.

Un-Sanctioned App Concern Is Just A Red Herring
Modern API management infrastructure like 3Scale, and WSO2, provide an unprecedented level of control over managing API access, requiring secure on-boarding of new developers, the establishment of service composition definitions, which provides rich real-time analytics on how APIs are used, and by whom—while also seamlessly integrating with existing identity and access management solutions. The university gets to choose who has access to which services, revoke access when abused, while also better understanding how resources are really being accessed and put to use. Ideally this applies to all campus-wide usage, as well as with external 3rd parties—modern approaches to API-centric operations, include the management of internal, partner, and public resources in this way.

A More Balanced Governance Across Campus Resources
Modern API management was born out of traditional IT governance, but is something that is more focused on giving access and control to the end-users who are the actual owners, of the valuable data, content, and other digital resources being made available. Legacy campus IT models provide a governance model that involves IT, administrative and faculty stakeholders, but rarely includes the students. APIs give students secure access to their data, and standards like oAuth opens up the ability for them to have a vote in who has access to their data, with oAuth scope being defined by existing institutional governance efforts. When APIs enter the conversation, governance expands to be more self-service, real-time, and within the control of students, as well as administrators, faculty, and campus IT.

Possibility Of Good Things Happening Closer To The Student
In the current educational environment, where students are often more tech savvy than faculty and administrators, why would we want to eliminate serendipity, and the possibility that new things might happen. Solutions to problems that students actually face everyday, that campus administrator may never think of, because they see technology through a very different lens. The days where IT knows best, regarding what devices, browsers, apps, and websites are optimal for getting things done, are in the past. Shadow IT demonstrates this, where students, and even faculty are using un-sanctioned solutions to get their work done. Campus IT should be empowering students, encouraging a more digitally literate individual who soon will be entering the workforce, not suffocating this.

Easy For Campus IT To Miss The Big Picture
I am a recovering IT administrator, so I understand the challenges a skeptic campus IT administrator faces, but ultimately by restricting access to campus resources just makes your job harder, making you the bottleneck that everyone's so commonly complains about, when it comes to IT. APIs don’t create more work for you, it makes you much more agile and nimble in how you integrate systems, build new web and mobile applications, and provide 3rd party vendors access to campus resources—as well as potentially opening up self-service access to students.

With an API-centric approach you will know exactly who is accessing resources, and how they are using them--in real-time. I’m betting that you don’t have this visibility across all of your IT resources right now. When I put on my IT director hat, I prefer the API model, because then all resources are self-service, available to only those who SHOULD have access, all without them having to talk to me. I’m left alone to do what I do best, and can also monitor new signups, real-time usage, and manage support tickets in accordance with wider IT support strategies.

I understand you are a skeptic about APIs being a thing students should have access to, and in reality most students will not care, but there will be a long tail of student users who will do things you never imagined, and potentially change how you look at scheduling, document management, or other staples of campus operations—something that will never happen if you don’t make students a priority when it comes to your digital resource management.

Disclosure: 3Scale and WSO2 are both API Evangelist partners.


Developer Support With Google Helpouts

I was cruising around the Google Developer area and I stumbled across Google Helpouts. A service being billed as “Experts with Answers, Meet Developers with Questions”. Seems like a more one-to-one version of Stack Overflow, where you can get the answers you are looking for when it comes to development on the Google platform, but in a more direct, one-to-one way.

Inversely, you can contribute your developer skills, and be one of the knowledgeable developers who are giving back to the developer community. The Google Helpouts page describes it as: Give Back - Continue Learning - Build Your Reputation. I signed up for an account, gave my profile, but the tags that I was able to connect with my profile really didn’t match my skills. It seems very programming language, and platform focused at this point--not really for APIs.

At first glance I thought Google Helpouts was more about Google APIs, available as an exentsion of the Google Developer program, but it seems to be a more tech focused, skills matching service. I think the same concept would work well, if applied to APIs, but I don’t see any reason for a new platform, just build it on top of Stack Overflow API—why re-invent the wheel?


Sales, Onboarding And Support In A Self-Service API World

I was reviewing an API over the last couple of weeks--I signed up for an account, came back several times, and made a handful of API calls in hopes of learning more about how the API works. This is something I do a lot, and it is always interesting to experience the on boarding process (or lack of) for APIs.

I first signed up about two weeks ago for this particular API, and within 48 hours I received an email asking if I needed help with my integration--that was nice of them. I like getting an email from the provider, and the more human it is, the better. At this point I didn't need any help, I’m just playing, learning, and depending on the self-service resources made available to me via the API ecosystem.

About a week later I get another email, again asking if I need help. At this point I’ve put down the API, but when I pick back up I might respond to the platform then, but I just have more learning to do before I have questions. Then about a week later, right before I was about to pick up the API again, I got another email asking me what my plans were, putting more pressure on me to share my plans for how I was going to be using an API, which I'm just not sure yet.

I am not your usual API consumer. I know this. However this API, I was actually planning on integrating into my core API tracking system at some point, so in addition to being the API Evangelist who might write a story, there is a good chance I will become a customer. I really like, and believe in the self-service nature of APIs, and while I like getting an email letting me know someone is home, I tend to be turned off by each consecutive email--nothing reminds you are in someones sales funnel, like a series of emails.

When you consider the touch points for your API on-boarding flow, make sure and think about the different types of users who will be registering, and the fact that not everyone will fit squarely in your perfect funnel definition. You want to make sure your API consumers know that someone home, and that you are there to help, but you really should rely on your self-service resources to get the bigger job done. Your initial email after I sign up should do this, then leave the next steps up to me, and be very thoughtful, and possibly dynamic with each engagement after that.


My Continued Support As Signer Of Oracle v Google Amicus Brief From EFF

As the Oracle v Google API copyright case was on its way to the Federal Circuit Court in 2012, the EFF reached out to me for help in crafting stories of how important it is that APIs remain free of copyright, ensuring they remain open and interoperable. I shared three stories, one on cloud computing and AWS APIs, the second on Delicious APIs, and the third on Instagram APIs, all reflecting three different scenarios that would never have happened if APIs were copyrightable.

A couple weeks ago EFF reached out again, asking for my signature again, on another Amicus Brief to support Google’s request of the Supreme Court to review the circuit courts decision, and reverse it. As it stands right now, there is a precedent that copyright can be applied to APIs, and even though the case itself is moving onto the question of fair use, if we let the current decision stand, other companies can follow Oracle’s damaging lead and sue for protection of their APIs--which is why we need to convince the Supreme Court to review, and overturn the very damaging decision. 

We expect that the Supreme Court will decide whether or not to grant Google’s petition to review the Federal Circuit’s decision sometime in January or February of 2015. So I need your help to stir up buzz around the issue, and post stories on your blog, call your congressman, and light up any other channel you can, to help educate people about the importance of the issue. When the Supreme Court takes on the case (which I feel strongly they will), we will need to regroup, and refile, a more expansive brief on the importance of APIs remaining free of copyright. 

I’m working to expand my restaurant menu analogy, to help people understand the importance of APIs, but if you have other analogies that you think would help the Supreme Court understand the separation of API interfaces, and their supporting server side or client side code, please share with me so I can work with the EFF to potentially include in the next brief that is filed. APIs are touching every sector of business in 2014, and if we allow Oracle’s copyright claim to stand, we are in danger of pouring glue into the gears of each of these business sectors, at a point in time where we need to introduce as much lubrication, and transparency as we possible can, to ensure that the web, mobile, and Internet of Things applications built on APIs remain open and interoperable--ensuring they serve not just their platform owners, but also developers, and end-users equally.

Join me, in helping bring awareness to the issue, which right along with Net Neutrality, is one of the most important issues we currently face when it comes to deciding the future of technology, and how our society works, shares, collaborates and interoperates in this new online digital world we have created for our world.


Wunderlist adds Dropbox support to help you better manage your to-dos


The mobile and desktop to-do list app Wunderlist has added Dropbox support, allowing users to automatically attach files stored in the cloud directly to tasks. The company said the move is the first of many integrations of third-party productivity tools and that Dropbox support in particular was one of the most requested features. To get started with it, all you need to do is click on the Dropbox item in detail view and select the file you want to add. If you then change that file in some way, those changes will automatically sync back to the file attached to Wunderlist, negating any need to reattach it. A spokesperson for the company confirmed that the new feature is avaialable on Wunderlist for the Web and Android from today and that it should land for iOS devices just as soon as Apple approves the updated app in the “next few days”.

URL: http://feedproxy.google.com/~r/TheNextWeb/~3/BqBAAUXu4gA/

If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.