Saturday, June 30, 2012

Twitter Continues to Restrict Access to Our Tweets

Twitter has become a global communication platform, allowing anyone in the world to express anything, from simple everyday thoughts, to ideas that some say have the potential to be the seeds of revolution. Twitter’s success was made possible because of open access to Twitter via the web and mobile phones via either SMS or native apps--with a large portion of this access made possible via an open Twitter API.

While the Twitter API is still showcased as an important part of the platform, access via the API is certainly not what it used to be.

While most every feature on Twitter.com is accessible via the API, overall access has been diminished through what is known as “rate limiting”. Rate limits began in 2007, to help limit the load on Twitter servers by reducing the number of calls anyone can make in an hour. But over 6 years these rate limits morphed into not just hourly limits, but to restricted access to Twitter increasingly valuable data stores--something that is not at all related to server stability.

Restricting Access

As the importance and value of the Twitter data grows, API access limits have become an vital tool for Twitter to tame the Twitter API ecosystem. Twitter has also slowly establish 100% control over web and mobile clients, while also setting the stage for the commoditization of Tweets, creating a new ecosystem where only sanctioned firehose partners are allowed to provide API access.

While the Twitter firehose began as a way to provide wider access to developers, and not as a monetization strategy, it has become just that--a way for Twitter to monetize each and every Tweet, leaving access to Twitter data looking something like this:

Provider Access Cost License
Twitter REST API 350 calls per hour and 1500 total Tweets via search and 3500 total for a user's timeline FREE Display
Twitter Streaming API 400 track keywords, 5,000 follow user ids, and 25 0.1-360 degree locations FREE Display
DataSift 100% Firehose Access Pay as You Go w/ 3K, 5K, 10K, 15K monthly tiers Analysis Only
No Display
Gnip 1-2%, 10% or 100% (filtered) Firehose Access Up to 50K / month depending on needs Analysis Only
No Display

As rate limits have evolved from hourly limits into overall data limitations, access has shifted to firehose partners. Most recently it has been handed to the two sanctioned firehose partners, slowly reducing access to Twitter’s API, and its value to developers.

Selling Access

In the past, even with hourly rate limits, developers were able to navigate through a Twitter search or a user’s timeline and go back in history without limitations. However over the past 2-3 years, history has been moved out of reach, by limiting the total volume of Tweets for a search, user timeline and other endpoints, clearing way for a new way to commoditize Twitter history:

Provider Timeframe
Twitter REST API 1500 total Tweets via search and 3500 total for a user's timeline
Twitter Streaming API Real-time, no historical access
Datasift Back to January 2010
Gnip 30 Days with more historical access coming

Twitter history is now off limits to developers via the Twitter family of APIs, with control relinquished to only two sanctioned partners, who are able to commoditize access to history only for analysis, not for display--leaving the ability to display of Tweets to Twitter.  When it comes to history, Twitter has provided access to the Library of Congress, but two years later they are still trying to find the best way to provide access to the archives, without any news of what they have or how they will share this history with the rest of us.

Marketing "Open"

Twitter started as a truly open API, openly accessible by the entire ecosystem, and over the last six years Twitter has actively marketed its API as an open ecosystem, encouraging developers to build. This has allowed Twitter to maintain the historical perception that they are an open API platform. In reality, developers who are building actual businesses around Twitter are not just limited, but actively having their access cut-off--leaving Twitter API access to only hobby level projects.  If you are looking to build a business on Twitter you need to use one of the Twitter resellers, which means you will have to spend thousands of dollars a month to get data.

Access to Twitter API has been a topic of discussion since they began rate limiting in 2007, but rate limits were not actively used to control what developers could build until 2010, when Twitter began its quest for monetization. This quest has involved controlling every Twitter endpoint as well as the brand, something that has historically involved developers. But since Dick Costolo has been at the helm, every aspect of the Twitter vision has excluded the developer community.

Control

As a API owner I understand Twitter’s need to maintain control over their brand and platform, but I feel their approach has severely damaged the entire open API movement. Twitter has actively maintained the legacy image of Twitter as an open API platform, encouraging developers to build, while quietly reducing access, stifling innovation around what is the most important global communication and API platforms in the world--a process which doesn't just destroy their ecosystem, but has damaged developer's taste for building with open APIs.

Analyzing the last six years of Twitter's history, it's very clear that Twitter does not have the respect for the ecosystem that has significantly contributed to the company's success. Beginning in 2010 Twitter saw developers as an obstacle to their goals for extracting value from the passionate user base, and monetizing the increasingly valuable stream of Tweets, that we generate on a daily basis, around the globe.  

Twitter wraps itself in the rhetoric of free speech, but has done nothing but restrict the voice of the developer and everyone's access to our Tweets.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/jYMRrS_woPY/

Friday, June 29, 2012

The API Economy Welcomes Its Early Trade Wars

I’m on a roll tonight, writing about tension between API owners and consumers. After some driving around California this week, I’ve had time to ponder three recent episodes with Netflix, LinkedIn and Craigslist. This is my last post tonight, and was inspired by a Tweet from James Watters (@wattersjames):

I thought about his Tweet for the last week and he’s right. While it’s easy to run and get our pitchforks in these situations and demonize API owners, or bitch about how much API developers suck, this all is just the beginning of something greater--the API economy.

Trade wars are an active part of our global economy, and with the growth in the number of APIs, the tension between API owners and consumers is only going to grow. We can’t see them as black or white, we will have to evaluate them on a case by case basis.

I think my three posts tonight reflect the potential diversity in issues.

  • Netflix - The movie industry isn’t quite ready for public APIs, other change required first, sorry developers
  • LinkedIn - A little communication can go a long ways in how we approach terms of service violations
  • Craigslist - Sometimes the market just demands that you need an API, allowing you to tame scrapers

James Watters Tweet definitely made me look at this issues in a different light. And that is what I love about this space, it is constantly changing, forcing me to constantly reevaluate how I see things and tell stories in the space. And even before I can finish this post John Sheehan (@johnsheehan) has got me thinking about another angle all three of these stories share:



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/eHXrMlVN19M/

Wednesday, June 27, 2012

What Does Your API Do?

After looking at over 6000 APIs, the most irritating thing for me when reviewing an API, is when I have to work to figure out what an API does.  Many APIs just don't communicate what their API does and articulate the value for developers.

Every API should have a quick introductory paragraph at the top of the first page that clearly defines the API in 250 words or less. Many APIs have a description, but it often reads like this:

The [Insert Company Name Here] API delivers programmatic access to all the features available in the [Insert Company Name Here] web application. Developers can use the API to build web and mobile applications using the functionality it provides.

Ok? You just told me nothing. I have no idea what your core web application does, or your API. The second worse offense I see API owners commit, is they get all RESTful on you:

The [Insert Company Name Here] API delivers RESTful access to the features available in the [Insert Company Name Here] web application. Using the API you can construct URLs and GET or POST information to the API and receive either XML or JSON responses.

Ok? You just told me nothing. You gave me a brief introduction to REST. Not very helpful. Often times I have to go to the parent website to figure out what a company does, before I understand the value of an API.

As an API owner, make sure and provide a quick, concise description of your API and the value it delivers. Don’t assume developers are in your head or understand what your company does. When writing your description, give it to someone who knows nothing about your company and see if they can figure out what it does.

I shouldn’t have to work to understand what your API does. Describe the value to me, quickly make me understand how it will help me, so I have the motivation to move past your main page, dive into your documentation and begin integrating.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/YCDzTO7eYTg/

Sunday, June 24, 2012

Tension Between API Owners and Consumers

We’ve had a couple of new API ecosystem flare ups in the last week. one from LinkedIn and the other from Netflix. I’m still working on my thoughts about both of these, but in the meantime I can't help but think about the tension between API owners and their consumers. This tension doesn’t exist in all ecosystems, but seems default by nature in others.

In these flare ups, I can’t help but empathize with both sides and see each others perspective:

  • API Owners - This is my company, our resources and our brand. I may “eat our own dog food” to show I share your pain, but I really don’t understand the developer perspective because I don’t use other people’s APIs, let alone depend on them for my business livelihood. I appreciate the work that’s going on within the ecosystem, but I also have to keep my bosses happy and maintain relationships with our partners and vendors.
  • API Consumers - It’s hard when I can’t figure out an API or find the right info that will make it easier for me to on-board. It’s even harder when there is nobody to respond to my questions. It really frustrates me when I can’t get the access I need to be successful, even when I’m willing to pay. It’s even worse when I spend tens or hundreds of hours on a project or startup idea only to see you build it or even worse cut off my access because you feel threatened by me.

Both sides of the ecosystem can get along, you see it happen with APIs like Twilio, Stripe and even Amazon Web Services. There will be problems within ecosystem, but not all APIs are looking to screw over developers and not all developers are looking to exploit APIs.

I think in the beginning it can be fairly easy to maintain order in an API area, but as it evolves and the community of consumers grows, it can be difficult to find balance and maintain perfect alignment between the owners and consumers goals. But I think through the right amount of transparency and communication, both sides can find the right balance.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/VpWaULBYirw/

Tuesday, June 19, 2012

The 100% Open Source API Platform I Was Looking For

This is a much quicker follow-up to last week’s post, Where Is The Open Source API Platform, than I anticipated. I just finished a demo of WSO2 API Manager, a completely open-source API management platform.

I got quite a few emails and DM’s from folks after that post, and while there are other open-source API offerings like API Axle and Cumula (which I will write about separately), I was looking for a full platform tool, and it appears WSO2 is what I was looking for.

WSO2 API Manager is a simple, easy to understand API platform, but has all the hardened enterprise goodness many of you will be looking for when it comes to security, governance, policy enforcement, etc.

The platform is broken into three main buckets:

  • API Gateway - To secure, protect, manage, and scale API calls
  • API Publisher - Enables API providers to easily publish their APIs, share documentation, provision API keys, and gather feedback on APIs features, quality and usage
  • API Store - Provides a space for consumers to discover APIs functionality, test APIs online, subscribe to APIs, evaluate them and interact with API publishers

They break the API users into what I think are important target segments:

  • API Creator - The technical owner of an API
  • API Publisher - The business owner of an API
  • API Consumer - The developer or consumer of an API

I really like this distinction, because it acknowledges that many APIs are not born out of technical departments, and allows for duel ownership of any API from the technical and business disciplines-- which is very important to the success of an API.

WSO2 API Manager meets my vision because its a platform that has the identity, proxy and other essential technical pieces, but provides an extensible platform to deliver the other building blocks for a successful API like documentation, code samples, how-tos, forums, etc.

WSO2 has a target of end of July for the version 1.0 release, as well as an aggressive roadmap for adding other features for billing, etc. I’m going to download the current version and start playing with to get more familiar with, and hopefully be able to provide a more detailed review of the open-source API management platform.

It’s too early to tell, but WSO2 looks to be the necessary open-source counter balance I was looking for, and the fact that it’s already in development shows me that the API space is even more healthier than even I anticipated.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/fd_7zCkZYKs/

Monday, June 18, 2012

Launching APIs One Book At A Time

Last May, Pearson Publishing began the roll-out of their new API platform, by doing initial tests using their DK’s Eyewitness Travel Guide material, before moving on to a wider range of subjects. By the end of the summer they had rolled out a total of three APIs:

A year later, they now have APIs for the Pearson Kitchen Manager and most recently the Nursing & Health Survival Guides API.

Pearson is obviously being very cautious with their precious business assets. Taking time to do it right when bundling up these resources and making available for developers via a RESTful interface.

The Pearson Developers community has many of the essential API building blocks like documentation, blog, forum, and FAQ. Registration for Pearson APIs is self-service, allowing me to immediately verify my email, login and begin exploring the APIs.

For support, Pearson provides a contact form while also maintaing an active presence on Twitter, and even provides a "report a bug" feature for each API.  The terms of of use for Pearson APIs is pretty liberal, allowing to me use their content in my commercial applications, even if I use advertising.

Pearson has a done well in opening up their content with APIs. They’ve done it wisely, requiring registration so they can track how its used, but keeping registration self-service and providing sensible terms of use, so they are protected, but also giving developers enough freedom so they can get to building apps and innovating around their content.

It makes sense for Pearson to take it slowly and learn with each API implementation, making sure they do it right. I think Pearson’s simplistic approach to opening up their catalog is a great example for other publishers to follow.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/1YVsbPOm04I/

Friday, June 15, 2012

Everyone is an API Evangelist in an API-Driven Company

I’ve had some amazing feedback on my post about the demand for API and developer evangelists. One great perspective was from the team over at Iron.io, who do cloud messaging, event handling, workers, scheduling and provide a key/value data caching.

Ironi.io’s has a unique company philosophy that addresses the need hire an API or developer evangelist. Their approach is that in an API-driven company everybody is an API and developer evangelist. Iron.io has their entire team monitoring their public chat, which has lead to everyone in the company understanding customer pain points as well as hearing the praise and positive feedback from the community.

While it sounds simple, spreading core philosophies like this company-wide can have a transformative power. Think of Amazon’s success after Jeff Bezos mandated that, "All teams will henceforth expose their data and functionality through service interfaces."

Sometimes it’s the little things that can provide huge shifts in how we think. A cornerstone of my API Evangelism philosophy is internal evangelism within a company about the power of APIs, in addition to public and partner evangelism. Iron.io’s philosophy changes this for me.

I know that not all companies can make the shift to API-driven companies, but if an entire company can adopt an API-centric frame of mind and share the evangelism role across the company, there is no need for a single API or developer evangelist.

Maybe API evangelist is more of a philosophy than an actual role your company needs to fill?



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/jCnsSB7qs40/

Roundup of 20 API Service Providers in 2012

Its been over six months since I did my roundup of 11 API service providers on ProgrammableWeb.  I've been seeing enough new entries into the space, I think its time to do another roundup, providing a single list of API service providers for you to explore.

I will start with I called the grandfathers of the space.  The ones who were doing it before APIs became all cool.

Atmosphere - The SOA Software, Atmosphere™ provides a secure, robust platform that companies can use to share their APIs with the developer community of their choice. SOA Software Atmosphere manages, monitors, and secures companies’ APIs ensuring that they deliver the level of service customers and partners require; the security of corporate and customer information and assets; and the integrity of the corporate brand. 

Layer 7 Technologies - Layer 7 is a leading provider of security and management products for API-driven integrations spanning the extended hybrid enterprise. Layer 7 products simplify the management of open API for developer communities, partner and cross-divisional integration via SOA, cloud connectivity, and enterprise mobile enablement for BYOD (bring-your-own-device) initiatives. 

After my post in October of 2011, two other providers came out of the woodwork and said, "Hey! what about us?  We've been doing this a while too!"  So I have to include them this time.

Intel - Intel® Expressway Service Gateway provides an enforcement point for REST web services messages and can delegate authentication and authorization to identity management and PKI systems such as Active Directory and CA* Siteminder. It provides a secure point of entry to fend off denial of service threats, code injection, and other malicious traffic. 

Vordel - Vordel API Gateway is a policy enforcement point to authenticate API clients and users against enterprise access management platforms. Vordel adds advanced capabilities such as security token mediation for single sign-on and identity federation. Vordel API Gateway also integrates with fine-grained authorization tools to externalize authorization for new and legacy applications. Vordel offers out-of-the-box integration with all the leading identity management platforms to provide comprehensive API Security. 

Then there are the three major players in API management, that have been dominating the current landscape:

3Scale - 3scale provides an Out-of-the-Box Cloud API management Platform & Infrastructure for developers, and companies to securely open, control, manage, operate and monetize their API to 3rd parties (e.g. developers, business partners, etc). 3scale API management platform is Plug and Play, configurable, flexible and scalable and brings API providers an unparalleled level of ownership, control and configuration to ensure QoS, SLA and a great user experience.

Apigee - Apigee provides a range of solutions from entry level tools for exploring APIs with a console and navigating OAuth, to enterprise tools for managing OAuth, Keys and platform for driving developer adoption while understanding usage, managing traffic and scaling an API platform. Apigee provides solutions for enterprises like Comcast, GameSpy, TransUnion Interactive, Guardian Life and Constant Contact and thousands of developers use Apigee's technology. 

Mashery - Mashery’s API management tools and strategic services help companies connect with customers and partners in a changing digital world by extending reach across devices, markets and the Web. Mashery leads the industry with a holistic approach for API initiatives – from setting platform strategy and measuring business objectives to the heavy lifting of providing and managing infrastructure to facilitating relationships with our 130,000 strong network of Web and mobile application developers. 

I left one provider out of my last service provider round-up, which is ironic, since the post was on ProgrammableWeb, which is owned by Alcatel-Lucent:

Alcatel-Lucent - The Alcatel-Lucent Open API Platform (OAP) is an API Monetization and Optimization software solution, for Service Providers to turn their data and telecommunication infrastructure into a commercial transaction platform. OAP provides the expertise, tools and services for API management, API design and creation, reporting and analytics for optimization of API programs, business model design for maximizing revenue and service integration for time to market. Using OAP, Service Providers are able to create and securely expose new services, either directly or via composite APIs, so they can be made available internally and/or to 3rd parties, allowing for the creation and delivery of new offers to market, faster, at lower cost and at scale.

Next there are several companies focused on APIs for your data.  Last year I included InfoChimps, which has pivoted since then and is more a big data platform now.  I'm going to go ahead and bundle Socrata in with the remaning data API providers:

Kasabi - Kasabi is a marketplace for people publishing and looking for data. As a complete platform for the hosting and publishing of Linked Data, Kasabi brings together anyone involved with data: businesses, developers, individuals, organisations, government etc. Anyone can be a data publisher. Whether you have pubic-domain data to share, or you are looking to explore the business potential of datasets, Kasabi aims to support your model. When a dataset is created in Kasabi, it is automatically equipped with a set of APIs. These APIs give developers a range of options for instantly accessing data using standard authentication and simple formats. The Developers’ page has more information on working with Kasabi’s data and APIs. 

Socrata - Socrata is the leading developer and provider of Open Data Services, a category of cloud-based Web 2.0 solutions that enable federal, state, and local governments to dramatically improve the reach, usability and social utility of their public information assets. The Socrata Social Data Platform™ is a turnkey information delivery platform that reduces lifecycle management costs for government customers while boosting their ability to disseminate relevant information and data-driven services to a wide range of audiences including citizens, civic application developers, researchers, journalists and internal stakeholders.

WebServius - WebServius provides a self-service tool for deploying, managing and monetizing datasets using an API. WebServius provides users with the ability to integrate and store data, and enable access to the data via a REST API with XML and JSON responses. There is support for planning, development, implementation and ongoing management of APIs generated from data sources. Using WebServius you can proxy an existing REST API or connect directly to a data service provider, including Amazon SimpleDB. Once data is integrated, WebServius allows you to create custom details, plans, promotions, policies and pricing for the data API you wish to publish. 

During the last post I had showcased two new players in the space:

Mashape - Mashape provides tools that enable developers to quickly deliver and consume APIs and offers a marketplace for listing APIs. Mashape provides tools for testing your API, code for generation of custom errors, components for user management and standardized API code language libraries in multiple languages. Once your API is ready for prime time Mashape provides a marketplace for listing your API, letting developers to easily discover and begin hacking with your API, in a social API community environment. 

Apiary.io - Apiary.io provides developers with a way to describe APIs using whats called an API Blueprint-a custom language that allows you to rapidly describe you API in a way that you can collaborate/version/merge as you're used to when coding. From this blueprint Apiary.io then generate API documentation, a debugging proxy and bug reports. Apiary.io also provides social and technical integration using Github, to integrate with where you are already deploying your code and collaborating with developers.

While Apiary.io was still in early beta, Mashape was open for business and is now out of beta. Now, in the first six months of 2012 I've tracked on six new players in the space:

API Axle - Apiaxle is a free, locally hosted API proxy that can sit infront of your API, providing key authentication, rate limiting and statics. Apiaxle is an open source API proxy, allowing you to install yourself, modify, make changes and contribute back, and be part of a larger community all contributing to the platform. Apiaxle is built using node.js, Nginx, and uses Redis as a datastore.  

Apify - Apify is a small and powerful open source library that delivers new levels of developer productivity by simplifying the creation of RESTful architectures. It helps development teams deliver quality web services and applications in reduced amounts of time. Web services are a great way to extend your application, however, adding a web API to an existing web application can be a tedious and time-consuming task. Apify takes certain common patterns found in most web services and abstract them so that you can quickly write web APIs without having to write too much code.

APIphany - APIphany® is the most flexible, dynamic, well-engineered, and reliable API management platform. We can manage any API hosted anywhere on the Internet, regardless of implementation technology. Our platform provides the tools and guidance to support you in every API lifecycle phase. APIphany development and operations teams consist of rocket scientists with 100+ years of combined experience in developing and running sophisticated, Internet-scale software systems, on a variety of platforms, using a diverse set of technology stacks. Skilled in both API implementation and API consumption, we know exactly how to launch and manage APIs, supporting thousands of partners and developers.  

Emergent One - Emergent One is an API platform that allows you to quickly generate and launch a new API from MySQL or Postegres databases connection. After launched a developer portal is providing API registration, documentation, blog and console. Emergent One automatically generates documentation and code samples, and provides access controls, caching and analytics for managing your API.

Nevatech Sentinet - Nevatech Sentinet™ is a flexible, lightweight and scalable API management platform that promotes integration through the use of SOA standards. It is designed to connect, mediate, and manage interactions between services across the enterprise or in the cloud. If your organization uses internally or externally-facing web services and APIs, cloud-based infrastructure, or service-oriented architecture for your applications, then you will find Sentinet to be a powerful tool, which can be deployed rapidly, and immediately start delivering tangible results.

WSO2 API Manager - WSO2 API Manager is built on proven, production-ready, components from our integration, security, and governance offerings. WSO2 API Manager consists of an API policy enforcement gateway and collaboration space where API publishers meet API consumers. The collaboration space consists of an API Store and API Publisher. The lean software development process leads to an important customer benefit; our cost. WSO2 API Manager offers significant time saving and affordable acquisition. Purpose-built for rapid configuration and efficient extension, users agree the product is easy to configure and extend. These attributes leads to lower overall costs and higher ROI  

That brings a total of API service providers to 19.  There are other providers that deliver services API owners can use, but the companies I've included are focusing specifically on providing services to API owners, and a growing focus on delivering services just for developers.

I'm in talks with several other new providers as well, who aren't quite ready at the time of this post.  One such company is Webshell, who is developing a scripting language designed for fast API consumption and implementation. After a demo I think Webshell could open up new ways for us to consume, not just single APIs, but many APIs mashed up together creating entirely new API interfaces and interactions.

Any way you look at there is serious API innovation going on in 2012, its an exciting area to be part of.  If you know of any API service providers I missed, make sure and drop me a line. 



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/KFRTdfCo2ks/

Monday, June 11, 2012

The Demand for API and Developer Evangelists

I just got off the phone with a recruiter of a major API management company, looking to recruit me as a developer evangelist, and last week I talked with two companies looking for developer evangelists.

My profile comes up in a lot of searches on Google, LinkedIn , and with the growing number of APIs, the number of companies looking to fill the role, grows as well. It makes sense that I come up in searches and get a regular stream of calls.

Most recruiters I decline, as I’m looking to pay attention to the bigger picture, beyond just a single API--and tell them I will put out a signal to my network, about the role. I do this knowing, there really is nobody to fill the role.

The recruiter today asked an interesting question. If you're not available, what type of person should I be looking for? In my mind, an evangelist should be equal parts:

  • Engineer
  • Product Development
  • Business Development
  • Sales
  • Marketing

So if you can find anyone coming from one of those disciplines, but has the technical chops and isn’t afraid of programming-I recommend starting with whichever of those skillsets is most important to you.

Ideally you want to find someone who has been programming for years, but recently has been a lead developer or architect, and has upper management experience as well as understands the business and customer end of operations.

If you fit the profile of an API or developer evangelist, or are just curious about the role, drop me a line I’d like to talk more, there is potentially a huge demand out there for your skills.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/4F8YT2x9qks/

RESTGit - Deploying APIs from My Github

I have a workflow for dealing with the steady stream of ideas that fly out of my arse on a daily basis. First, I write them all down in Evernote. If an idea sticks with me and keeps nagging on me in the back of my mind, I usually give it a place on the internal wiki that I use for managing my world. Then if an idea sits on the wiki for over a year and I haven’t finished building it, and successfully deployed or integrated into my platform--I set it free.

The one year expiration date has come for one of my ideas, and I want to publish here so maybe someone else will run with it.

  • Project Idea: RESTGit
  • Summary: A RESTful interface for any public or private Github repository.

I just want a quick way of throwing up a RESTful front, with or without authentication using 3Scale API management. RESTGit would deploy any flavor of language I choose: PHP, Python, Ruby, Java or anything else.

This way I could take select code resources I possess, commit them to a Github repository--then point RESTGit at the repository, and it would generate a REST framework and allow me to customize and adjust as needed.

RESTGit would be open source of course. It could be deployed as an Amazon EC2 instance, letting me rapidly deliver APIs for any resources I posses and scale as needed using AWS.

I wish I had more time to invest in my side projects, but I’d rather see it implemented. Hopefully one of you readers will find the time to develop RESTGit and open source it for everyone to use.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/qQ97VguPSSY/

Where Is The Open Source API Platform?

Every couple weeks I get posts that really strike a chord with my audience, like Barack Obama Directs All Federal Agencies to Have an API, which has received 40K+ page views and 1000+ tweets. When it comes to sustained traffic numbers, two posts seem to really bring in eyeballs each and every week via organic searches:

These posts are successful, not because of searches driven from a couple of hours on the home page of Reddit or Hacker News, these get page views because users are searching for open source API tools on the open Internet. Seeing these sustained numbers validates for me the need for an fully open-source set of tools for API deployment and management.

While the top API management service providers like 3Scale, Apigee, Layer7, Mashery and SOA Software are enjoying growth in API adoption, to reach a million APIs and a truly healthy API industry, we need a solid open-source API platform that provides:

  • RESTful Framework for Deployment and Management
  • API Analytics and Metering
  • API Service and Billing Management
  • Ecosystem Building Blocks Like Documentation, Code Samples, etc.
  • Discovery

I know there are individual tools that deliver in some of these area, and this is what I am working to bring together via the API Evangelist tools section. But we need a full suite of tools that API owners can deploy from start to finish, and service providers can benefit from as well as contribute to--something in PHP, Python, Ruby and / or Java.

While looking through thousands of APIs I notice that many of them go silent about 6 months after launch, which tells me many of them spent their resources on development, deployment and initial management--not leaving resources for properly handling the business of their APIs, allowing them to evolve, pivot and find success.

To get the API industry where we need it, we need thousands of more companies jumping in. Many of these companies won’t be able to afford the services of Apigee, Layer7, Mashery and SOA, and with 3Scale and Mashape being the only entry level API management platform(there are others emerging), there is a huge need for an entry-level, open source API offering.

Since I’m one of the only vendor neutral players in the space, I’d love to solicit some partners to help make this happen. Even if version 1.0 involves bundling of existing open-source tools, I’d like to kickstart a truly open-source movement for the API space.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/D-p-AZeEosg/

Wednesday, June 6, 2012

Brand Control Within An API Ecosystem: Twitter Edition

Right after security, controlling your brand is the biggest concern I get from companies interested in deploying APIs. They are worried about being able to control their brand and overall message portrayed by their potential developer community.

Branding guidelines and a robust image, button and UI gallery is something I encourage API owners to invest in from day one, because it’s easier to set the stage early on than trying to take control after the unicorns are running wild.

One example of this is the darling of the API industry, Twitter. Twitter has took further control of their brand today, with the release of #Twitterbird. As Twitter states:

Starting today you’ll begin to notice a simplified Twitter bird. From now on, this bird will be the universally recognizable symbol of Twitter. (Twitter is the bird, the bird is Twitter.) There’s no longer a need for text, bubbled typefaces, or a lowercase “t” to represent Twitter.

The #TwitterBird is the latest addition to the Twitter Trademark and Content Display Policy, where Twitter lays down the following branding guidelines for the Twitter ecosystem:

  • Assortment of Twitter approved images
  • Dos and Don'ts of using Twitter images
  • How to use buttons to promote your Twitter account
  • Use of Twitter brand in advertising and marketing materials
  • Use of Twitter brand in merchandise and manufactured items
  • Naming your applications, products and domains
  • How to visually design your website
  • What to do when your writing a book or publication about Twitter
  • How to display Tweets and other Twitter content

We’ve come a long ways from 2008 and 2009 where logos, buttons, badges and other Twitter branding items were yet another area where Twitter depended on the Twitter ecosystem for support. The Twitter community created a wild assortment of assets to be used when integrating Twitter into your site or application.

Then starting in 2010 Twitter started pulling in the reigns and took more control of their brand with the release of a set of “refreshed...logos, buttons and widgets to bring the improved look and experience of the new Twitter to your website or blog”.

Over the next two years Twitter has continued to polish their brand, while also tightening the rules of how you can use Twitter and Tweets in your own sites and applications. While I totally understand Twitter’s need to get more control, my only criticism are:

  • Four Years Late - They should have done this a long time ago. It took four years before they started doing anything in branding.
  • Developers - They should have included the ecosystem in more of the planning as well as creating a layer that includes ecosystem apps in the equation

It’s easy for me to sit here in the future, telling Twitter what they should have done, when they were the pioneering API company. But I feel pretty strongly that many of the decisions in the last two years to gain control of their ecosystem, would have been better off started from the beginning, and also suffers from a severe shortage of ecosystem involvement.

While I can’t change Twitter’s approach to the Business of their APIs, I can help influence the next generation of APIs. Make sure you consider a healthy and complete branding resource center for your API, and consider how you can protect your brand while also empowering your developer ecosystem.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/EqB5VQhWMKk/

Tuesday, June 5, 2012

0 People Found This API Useful, Be the First!

I just wrote a post on how the iContact Developer Area delivers, and now for an API area that doesn't quite deliver.

Notice the text in the bottom corner, 0 people found this useful. - Be the first!

Default wiki settings might now always be the way to go, when your trying to deliver a marketing message about your API!



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/xR-SDmdmHpw/

iContact Developers Area Landing Page Delivers

I look at a lot of APIs, the first page you land on makes a big impression, and I can always tell when someone cares enough about developers to craft a simple, quality API Area landing page.

I’ve talked about what it takes to qualify for my API stack, and today’s winner for simply and elegantly qualifying for the API stack is iContact.

Upon landing on the iContact Developers Area main page I visually see what I need to get going:

  • Get Started
  • Self-Service Registration
  • Documentation
  • Code Samples
  • Resources
  • Blog

Then in the footer you can immediately connect with other areas of the company:

  • Legal
  • Twitter
  • Facebook
  • LinkedIn

The iContact Developers Area landing page is well crafted and as a developer, makes you feel like someone considered you while designing. You can quickly get at what you need to start integrating and you feel like someone is there to support you as well as keep the API up and running.

What impression does your API area landing page say about your API?



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/QpQ2DOs2MT4/