When publishing an API, there are two preparatory steps to take before jumping into implementation. First, create metrics for determining the success of your effort. Secondly, take a good look at what you already have so that you can find out what you need to do before you publish.

In helping dozens of customers prepare their APIs for publishing, Mashery has observed what works, what doesn't work, and what is on the horizon. Here are some of the lessons we have learned.

Get Your API Ready

It appears that beyond the enterprise, SOAP is being left in the dust. REST is now the dominant approach in API publishing. The advantage of REST is that it is explicitly built on top of and leverages HTTP in ways that web developers are already comfortable working with. This makes development faster and easier. JSON-RPC is exhibiting growth as developers seek to integrate natively with rich JavaScript-powered user experiences. XML-RPC appears dormant and is used less widely than SOAP and REST. The emphasis has decisively shifted in favor of making content easier to consume, and if you use an approach that allows REST or abstracts to REST, you will be making life easier for developers who want to use your API.

What does this mean if you are already internally using an API that has been built around SOAP and want to publish it? At Mashery, we use protocol transformation to allow customers to deploy a REST implementation of a SOAP-based API. There are a variety of techniques for protocol transformation, and the approach we take depends on the API and the development tools being used.

Your API may also need to be cleaned up, split from a larger API set, or both. It is not uncommon for an internal API to develop cruft over a long period of use, and sometimes calls that are fine for internal use are too sensitive for use in a public API. Larger established companies frequently have a patchwork of APIs from having acquired smaller companies over the years. In all of these cases, there are workarounds that will allow you to publish a "lite" version of your API, giving you some breathing room as you build a new and improved API. For example, method limiting or filtering can be used to strip out unwanted elements from the WSDL.

Be Careful Abstracting Network Calls

Recently there has been a big push to abstract network calls by mapping API method calls directly onto server-side object methods. This may not always be a good idea because treating server-side objects and client-side objects as equals via web services can lead to serious inefficiencies.

For example, consider exposing a data access object directly via a web service. Broad-ranging queries to that object may result in very large quantities of data being pushed back through the web service. Now imagine that web service running on a mobile application over an EDGE network. By exposing the data objects in such a way that local and remote access to the object is treated equally, the result may very well be an unusable mobile application.

Instead, invest the additional time in crafting a broader suite of web services that access data in ways that are most commonly used, so that the smallest possible payload can be returned. In fact, building an API specifically for mobile web use will help you identify potential roadblocks early. The end result will require more up-front design work on the API, but will also yield higher-performance mobile applications and blazing-fast traditional web apps.

As with any optimization approach, moderation is best. You also do not want to wind up with an over-abundance of small calls when a handful of medium-sized payload calls will do the trick. You may want to consider support for batch-style operations in your API, so that a series of calls can be sent in one request, and the result of those calls chained together can be returned as the batch call payload.

Make It Cacheable

If you can cut down the number of round trips between client and server, you can increase the overall performance of your API. The more data you can cache, the easier it will be to cut down on those round trips. So, look for places in your API where uncached data is being used and, where possible, make that data cacheable.

The payload of an API call sometimes has a lot of uncached data; for example, a key value that is passed back each time the call is used. Sometimes extra payload data is inserted for debugging purposes, particularly with JSON-RPC, but it is easy to forget to remove the extra data from the payload later. Elements and attributes that are uncached can seriously reduce the overall performance of an API, while also increasing server resource use. Strip out the uncached elements and attributes and you will likely see a noticeable performance improvement.

Mashery has implemented caching for customers who need faster response times. The results are impressive: they usually see performance improvements of 50% or better for cache-related calls. If it is cacheable, you should cache it.

Remember, a New Approach Is Always Just Around the Corner

Earlier we mentioned that REST is the most popular approach for API publishing. But nothing lasts forever, and no technology is completely future-proof. The important thing is to pick an approach and maintain metadata. It is always easier to move from more metadata to less than the other way around, so think carefully about what metadata you need now and what metadata you may need in the future.

If you are using REST, consider WADL (Web Application Description Language). It is essentially WSDL for REST. While it is arguably not as easy to use as REST, WADL provides excellent metadata, and some useful tools are available, such as REST Describe & Compile, a WADL editor and compiler. Using WADL may seem like a bother now, but at some point, whether in 5 years or 15, you will have to transition to a different format. Having an excellent set of metadata will make that transition much smoother.

Pulling It All Together

Your API can be a tremendous strategic asset to your company, but it pays to plan ahead. Define your metrics, rid your API of cruft where possible, and filter it out where necessary. If possible, stay away from high-overhead techniques like SOAP. Remember that whatever is hot now will likely be eclipsed sooner than you would like, so build in as much metadata as possible. Pay attention to these rules of thumb, create an API with useful calls, and you will be off to a great start.

If you enjoyed this post then check out Mashery.com, the leading provider of API management services.

API publishing is no longer the future; it has clearly arrived. Companies from Best Buy to MTV Networks have jumped into the game, and more are taking the plunge every day. But what differentiates a successful API program from one that "never leaves the station"?

Before you can determine outcomes, you need to define the criteria by which you will evaluate the progress of your API program. It is important to realize up front that direct revenue is not the only metric; in fact, focusing on immediate revenue at the expense of longer-term benefits can be an expensive diversion.

Look at your API program from a bird's eye view. Are you trying to create entirely new revenue channels, or is brand awareness your primary mission? Are you trying to add more partners to existing programs, or are you more concerned with extending the reach of your interactions with customers?

Well-defined expectations are key, but there is an important corrolary: you need to be ready to take advantage of unplanned opportunities. Michele Azar of Best Buy recently described how opening the company's API to Geek Squad employees produced unexpected benefits. By moving quickly to harness the energy of these employees, Best Buy produced immediate, tangible results.

Measure Outcomes

Depending on your goals, some metrics will be more important than others. However, it is worth keeping tabs on all aspects of your program. API publishing is a process of discovery. Having a plan is imperative, but you will likely need to adjust that plan along the way. A clear 360-degree view of how your API is being used will give you the ability to make those adjustments with confidence.

Here are some metrics to track that we have gathered from our customer base and want to share with you:

APIs can reverse the traditional business development model. Instead of looking for partners, you can use your API to attract potential partners and to function as a vetting mechanism. Those developers who are doing good work with your API will likely be inclined to engage with you further. Be sure to delineate which partners are coming in via your API program; you may be surprised at the cost effectiveness of your program as a business development tool. By making its API available for commercial as well as typical non-commercial use, the Calais team at Thomson-Reuters saw a five-times increase in its business development pipeline in just a few short months.

One of the keys to tracking the success of an API is measuring traffic back to your site. How do you know who has sent you the traffic, and how do you make sure they link to you if you give them the content? Just as with Google Maps, making your content and services available for free will require that your terms of service include some level of attribution. This attribution will allow you to track the traffic back to your site from each partner.

Depending on how your API is being used, applications may provide entry points to a subscription-based service you provide. Thumbplay and Dada Entertainment are both off-deck mobile content providers that seek to register subscribers to their services. They have opened up their APIs to allow new affiliates to help them sign up subscribers. In turn, they compensate affiliates for each new subscriber. At the Business of APIs conference in early 2008, Thumbplay talked about the short-term results of its recently launched API program. It took the company two years to get to 40 partners, but with its API program it acquired the next 40 active affiliates in six weeks. Measuring the number of subscribers that come from its successful API program has become a key part of Thumbplay's monthly board meetings.

Reaching beyond your website can improve customer satisfaction and interaction. Mike Hart, Director of Engineering, Web API for Netflix, describes this as "delighting subscribers." The company is giving customers access to new means of interacting with Netflix. The measure of success for off-site interaction is called an engagement metric. Users can interact with content and services elsewhere on the web, and Netflix measures the ongoing engagement by watching the API activity on its partner sites. The higher the API calls, the higher the engagement.

CBS Interactive built a new API with the specific aim of weaving its disparate online properties together more tightly. An internal dashboard allows managers of various CBSI sites to easily integrate content from other CBSI properties. The time savings from this streamlined workflow is not just a good way of saving frustration: it is also a serious cost-cutting tool. In such situations, analysis is not a luxury; it is an imperative.

One large media company recognized that by launching an API program, it could reduce the cost of internal development. With the API, it can now deliver one to two new products and 50+ features each month to its service. In today's economic environment, this might be a valuable measure of the program's success.

Some of the more mature API programs, such as those of Salesforce.com, eBay, and Amazon, measure things like "number of transactions that occurred through the API." Take a look at your business functionality. Is there a growing number or percentage of transactions that occur because of partner API use?

Perhaps the most important thing to remember is that publishing an API is an ongoing project rather than an event. You have to stay engaged with developers, track what they are doing, and measure the impact of your program. Staying flexible will give you the ability to pursue those opportunities (expected or otherwise) that your program creates.

If you enjoyed this post then check out Mashery.com, the leading provider of API management services.

Getting Started

After signing up, you will be greeted with the currently empty dashboard, which gives you a few shortcuts to start customizing your plan with your company logo, invite your team members, and create your first goal.

As you customize your plan, you also get the option to set a default currency for your financial information. The default currencies are Dollars, Euros, Yen, and Pounds, but you can also change this to any other currency you might need.

Setting Goals

You goals can only fall into three categories: Solutions, Marketing and Sales, or Organization. While this simplicity makes sure that you do not unnecessarily complicate things by starting to micro-manage your goals, some companies might find this too limiting. On the other hand, as the folks at Organized Wisdom point out, PlanHQ is not so much a project management tool, but "an action management tool."

Correction: You can actually create your own categories, though this function is a bit hidden and can only be found in the settings menu. The folks at PlanHQ assured as that they were going to make this more obvious and add more links to these customization options in a couple of spots throughout the site.

The overall process of creating a goal is quite simple and asks you to define your goal, the importance of that goal, the team members responsible for achieving it, and, optionally, you can also send a message about the goal to your team and board members. Of course, you can also set the deadline for your goal here.

As is typical in this kind of application, once a goal is created, other users can comment on it and add attachment to it as well.

As you add more goals, you can then later reschedule them, mark them as done etc. PlanHQ will keep track of this and will gently remind you if you start falling behind at some point.

As PlanHQ's founder Tim Norton told us, some customers also use the goals feature as a bug tracking tool, with the advantage that all team members can easily keep an eye on the development instead of the developers working only in the silo of their own system.

Financials

The 'Financials' section of PlanHQ follows the same guidelines as the goal setting section, in that it tries to keep things simple, but without dumbing down the process. You can add information about your budget and actual expenses here and based on this, PlanHQ creates a number of graphs and general statistics indicating if you are on your path to profitability yet. It's important to note that PlanHQ here is trying to give you a general overview of your financials and that it is not a complete financial planning tool.

What was missing here, we thought, was the ability to import or export any of this data. However, we have heard from PlanHQ that they are planning on adding the ability to import and export spreadsheet in the near future and that they are especially considering some form of integration with the spreadsheet component in Google Docs.

Cost

PlanHQ offers a three month free trial for RWW readers, but after that, you will have to sign up for a paid plan. PlanHQ offers three different plans, ranging from $9 a month for a plan with 3 team members and 10 active goals, to the 'Small' plan for $24 a month and 15 active goals, up to the 'Pro' plan, which offers an unlimited number of team members as goals. Both the 'Small' as well as the 'Pro' plan include the ability to set private goals and connect through a secure SSL connection.

What About Basecamp?

Basecamp, at first sight, would be the closest direct competitor to PlanHQ (even the URLs are similar, after all). But even though they share a lot of functionality (to-dos, writeboard, milestones, etc., PlanHQ is more focused on teams and achieving goals. During our tests, it seemed that using PlanHQ would make it easier to focus on the big picture, while Basecamp seemed to invite more micro-managing.

Signing Up

PlanHQ is giving our readers a special deal: while you would normally only get a 30 day free trial, signing up through this link will get your thee months of free service.

Jigsaw came in for criticism when it first came along around 2006. But most services are raw when they debut, what matters is a) is the fundamental concept sound and b) can the management team continuously improve.

Jigsaw has top tier VC financing, so they can go the distance.

I chose Jigsaw to try because LinkedIn did not give me what I needed. I was searching for senior level contacts at a large company. LinkedIn gave me plenty of Level 3 contacts but I have learned from experience that Level 3 (somebody I know knows somebody who knows the contact) is not useful and can be a real time sink. So I only bother when I see a Level 2 contact.

I could pay LinkedIn to send an InMail to these contacts, but that is no better than sending a cold-mail and why spend money when there are free alternatives?

So my next stop was to Google the names. I saw Jigsaw coming up a few times so decided to give it a try. Fairly quickly I was able to get - at no cost - the contact details I needed. That is not as good as an intro but cold calling/mailing in limited doses can still do the trick.

There were some niggling irritations as with many relatively new services, but I did get value and the basic concept seems like it could be viable. Jigsaw works on a "pay or play" principle. You can just pay to get access to the contact information, as with any list. Unlike traditional lists, you can buy just one name. So this works well for selling high value stuff to senior people, not good for mass market spamming. Play means earning points by contributing contact information back into the system. They seem to have evolved good systems for managing this to avoid gaming and bad data.

So the data is user generated, as it is with LinkedIn, as opposed to scraped data from services such as ZoomInfo. Scraped data has value as well - you get the contacts that don't put themselves into LinkedIn.

However, data created by other people is not usually as good as data created by the person in question. I noted too many errors in my short stay on Jigsaw. I earned some points by correcting them, but this also made me question of the value of the data I had extracted.

I see some value in Jigsaw, if they can keep improving. I don't know how viable Jigsaw is as a business. It strikes me as an inexpensive service to run, so reaching profitability may not be too hard. But I don't know whether this can be a really valuable business in its current form. It is too easy to get email addresses in other ways (Googling the name and just using the corporate email standard) and you can always call via the company receptionist.

What has been your experience with Jigsaw? Have you worked with other alternative services?

Web Apps

Google App Engine: History's Next Step or Monopolistic Boondoggle?

The big news this week was the launch of Google App Engine, "a developer tool that enables you to run your web applications on Google's infrastructure." This will allow startups to use Google's web servers, APIs, and other developer tools to build a web app on top of. Google clearly has the scale and smarts to provide this platform service to developers. However, it begs the question: why would a startup want to hand over that much control and dependence to a big Internet company? Check out Marshall's analysis.

A new feature at ReadWriteWeb is an interactive game helping you to understand and contextualize web tech news in a fun way. This week we posted, via a new app from Impact Games, an interactive game that will let you model Google App Engine's impact in the marketplace. You can play the game here.

Our other coverage: Google App Engine: Cloud Control to Major Tom; HuddleChat: Did Google Just Rip Off 37Signals? and Google Takes Down HuddleChat After Complaints About 37Signals Ripoff

Related: Red Dog: Microsoft's Answer to App Engine and AWS?

How to Get Customer Service via Twitter

There has been a lot of talk lately of companies monitoring social media, be it Twitter, blogs, or social networking sites, for mentions of their company name and responding to customer service issues. Some of this interaction has been in the Twitter community, with Comcast being one of the more active participants as of late. Although in some cases, customers twittered their frustration after failing to receive the support they needed through traditional methods, in many cases, Twitter was the first place the customers vented their frustration, and then were surprised when they received a response from a support rep or company spokesperson.

Related: 5 Ways to Find More Friends on Twitter and Twittermethis Is A Brilliant Marketing Experiment

Seven Tips for Making the Most of Your RSS Reader

RSS is a big deal, as anyone who's subscribed to even a few feeds probably knows. Once you get past just a few feeds, though, it can quickly get overwhelming. RSS can leave you feeling inadequate, brain-dead and uninspired. Trying out new things will help you discover new, magical experiences, though. Letting go of the stress caused by any obligation to read everything will go a long way.

Here are seven tips for making the most of your RSS reader, from simple to more complex.

SEE MORE WEB APPS COVERAGE IN OUR WEB APPS CATEGORY

Web Trends

How Important is Offline Access, Anyway?

In today's world, you're never too far from an internet connection. In developed countries, broadband access is available in more places than ever, and even poorer countries have internet cafes sprouting up left and right. Modern web workers and business travelers even take extra precautions to maintain always-on connectivity - packing air cards in their laptop bags or buying laptops that already have built-in EVDO access.

Despite the broad availability of internet access, it's the dead spots that have been pushing forward the need for offline access to web apps. For how can a web office suite like Google Docs or Zoho compete with desktop software if they become unusable when the internet connection disappears?

Why We Need Web Apps on the Desktop

Sarah Perez conclued in the above post that offline access is important now, but not as important as it once was. And that with the increasing ubiquity of Internet access, it is growing less important every day. However Josh Catone thinks there is an important distinction to be made between offline access to web apps (as Google Gears provides) and desktop access to web apps (as Mozilla's Prism and Adobe's AIR provide). The latter is a very important step in the evolution of web apps.

Where to Find Open Data on the Web

This week there was a story on Techmeme entitled "We Need a Wikipedia for data". The article, written by X-Googler Bret Taylor, discussed the difficulty of finding open data sets on the internet, something which could spur innovation, allowing programmers to build new applications the likes of which have never been seen before. What was interesting about this story, in addition to, obviously, the concept of a Data Wiki itself, was the amazing and insightful commentary around this concept, not just on the blog, but all over the net, something which led to the discovery of some pretty good data sources that are already available.

A Guide to Business Development 2.0

At least once each day I get a call from someone trying to sell me outsourced development services. It's difficult to not be frustrated with these calls and it is increasingly hard to be polite, because they come so frequently. Yet, more than frustrated, I am just puzzled. Does this tactic still work? Who in this day and age would give business based on a cold call? These companies could definitely use a dose of business development 2.0.

Related: Marketing 2.0: Can Meebo Make it Real?

SEE MORE WEB TRENDS COVERAGE IN OUR TRENDS CATEGORY

That's a wrap for another week! Enjoy your weekend everyone.

Cold Calling is Dead

The reason we all hate cold calls so much is because they are very intrusive. A stranger interrupts our flow, and takes precious seconds away from our lives. But maybe even as recently as 10 years ago we did not feel it so acutely. Why? A few reasons. First, the pace of our lives was not as fast, the minutes did not feel as precious. But more importantly, today we have a much less intrusive form of solicitation - email. True we all hate spam, but an unwanted email doesn't feel like as sharp an interruption as an unsolicited phone call.

Besides being annoying, cold calling is no longer effective. People are smarter these days, and have learned to ignore upsells. A targeted email which avoids the spam box has a higher chance of getting a response than a call. With a call, the default allergic reaction is now "no." But with a brief and sincere email it could be, "hmmm, this might be interesting..." However, even cold emails do not work. To have a chance at making a sale, you need to get a warm introduction. It used to be that the business web was hidden inside of people's heads and rolodexes. Today, however, a lot of it is out there in the open - inside a digital business network called LinkedIn.

Warm Calling via LinkedIn

LinkedIn is a business network that has emerged as a substitute to the rolodex. Because it is online and self-managed, LinkedIn offers a much more robust way of maintaining your business connections and seeing what they are up to. But beyond that, LinkedIn has become an indispensable tool for business introductions.

Say you're interested in talking to Acme Co. about your new product. You log into LinkedIn and search for people who work for Acme. Then you see how you might be connected to them. Ideally connection is just one degree away, or in other words, you know someone who knows the person you are looking to connect with directly. And then you ask for an introduction.

An introduction received via LinkedIn is much warmer than a cold call, because it comes with a bit of trust. You are no longer a stranger trying to upsell things that no one needs, instead you come with a recommendation, however light, from a person that the receiver is connected to. And even if you can't find a path to connect to someone, sending a direct message via LinkedIn is better than sending a cold email. The reason is that LinkedIn implies business context, and so the person you're trying to reach likely is not going to be as surprised or angry about the unsolicited ping.

Creative Calling via Social Media

Beyond connecting on LinkedIn there are other modern means of connecting with people. Facebook message, Twitter @response, a comment on a photo or blog post, etc. These are ways of getting someone's attention that are creative, but you need to be careful when employing them because they can be unwelcome. People do not use Twitter to get unsolicited business pings, nor do they post pictures for strangers to comment on. Facebook is probably somewhat acceptable because a lot of people are mixing business contacts with friends there. But the most solid way of connecting with someone outside of LinkedIn is via their blog.

People who blog generally want to have a conversation. If you engage with someone around their blog and participate in a conversation on a topic that they are interested in, you will naturally connect with them. Particularly if your business engagement is relevant to the topic they are discussing, blog comments are likely the best way to engage. However, if you try to push the conversation off topic, the person will perceive you as disingenuous and there will be no business.

Transaction 2.0

Let's suppose you've found the right way to connect and you've got your meeting. Now you're looking at the whole sales cycle. Particularly, if you are small startup aiming to sell your product to a big company, has anything changed? Not really. You still have two fundamental hurdles - the time and the risk. Between startups and big companies expectations of how quickly the deal can get done are completely misaligned. Big companies are scared of the startup speed. Startups are frustrated with big companies' turtle pace.

Beyond the length of the sales cycle the issue that kills most transactions between startups and large firms is risk. Will this 5 person company be around tomorrow? That's a question that large companies are likely to answer with a "no" and that becomes a big problem. For this reason it doesn't make sense to buy from startups - it is too risky. However the mitigating factor is often cost - startup products are often cheaper or even free. Yet even if the technology is free and easy to remove if things don't work out, big companies are wary. They do not understand free, it scares them and perhaps rightly so.

The worst part about having a startup that sells to big firms is actually scale. The famous crossing of the chasm necessary to get big is really complicated. In the enterprise world, it means signing up many clients, keeping the pipes open, and sending out more and more products. This model is so costly and risky that venture capitalists are reluctant to shell out the money to fund it. Because of the complexity of building the enterprise business that knocks on doors a new model is emerging - web services and APIs.

Door Knocking 2.0: Web Services and APIs

How can a small start up that has no capacity to knock on doors sell to big companies? A possible answer can be via a web service or an API. The model is applicable to a whole range of services - from data plays like del.icio.us to messaging systems like Twitter to infrastructure like Amazon Web Services and semantic web services like Open Calais from Reuters. The basic model is to have a web service which is accessible via API (application programming interface). Clients sign up to use the service and have to agree to the terms in order to obtain a key. Using those keys, clients can use the service programmatically to send and get data from it.

Some examples: the del.icio.us API, allows clients to access information about specific users (if the user permits that). The Twitter API allows sending and receiving messages without using the Twitter web site. The Calais API is an example of a web service which encapsulates an algorithm. In this particular case, the algorithm takes a document and extracts semantic information from it. Unlike del.icio.us, which offers an interface to consumer data, Calais is a one shot deal algorithm. And perhaps the most important example of a web service play comes from Amazon. Taken collectively, the offered Amazon services is powerful infrastructure for building web-scale applications.

What is common between all these web services is the simple monetization strategy - pay per API call. For each call into the web service, the callee has to pay based on the amount of the resources consumed by the call. For example, Amazon has been charging for bandwidth, storage, and CPU time. The exact model does not matter as long as a fraction of a cent is charged for each call. Remarkably, this is a business that has a huge potential to scale. Each individual client is paying an affordable price, because each call into the web service is very cheap. However, collectively clients might amount to big revenue for the service provider.

What is the most attractive about this business model is that it is completely forecastable. By estimating the cost of scaling the business (mostly hardware, support and maintenance) and setting the price per web service call and the number of clients, you can determine if the business will work or not. Of course to be fair, we need to mention that just like in traditional sales, there is number of clients hidden in every equation. Two fundamental risks exist in this model - clients will not want to use the service and clients might not be able to figure out how to use it.

Still, the risks and costs of a web services based business are much less than the traditional enterprise approach. There is no need for an expensive sales force and an army of consultants to implement the solution. We are yet to see this model succeed in a major way, but because of their simplicity and straight revenue model the API based businesses are looking attractive.

Conclusion

Nothing stays constant in this world. The technology, the web and the society always evolve. Business development evolves along with everything else and lead generation has been changing along with methods of communication. Business networks like LinkedIn have replaced old rolodexes and email have made cold calling look ridiculous. Yet, there are no fundamental changes in the sales cycles and risks for startups that choose to go the traditional route of knocking on the doors of large companies.

The markets are iterating to come up with a new form of business development called web services. This new form is both cheaper and simpler - no enterprise sales force is needed to scale the business. However the question, "If we build it, will they come?" still remains unanswered. If any company can make this model work really well it is likely to be replicated and become widespread. Will web services succeed? Time will tell.

For now, please share your favorite examples and stories of business development 2.0 in the comments.