Integration has become very easy. API's and standards like REST (ok, not exactly a standard) and SOAP mean that anyone with an IDE can integrate. It's even become cool to use API's, and that scares me.

Why fear? Well, I've been doing "integration" for a long time. It's hard. Or, rather, it's hard to do well.

It's not about the connection, which is now easy. It's about the best practices that we've developed over years to prevent problems down the road.

I wanted to share one of the immediate benefits of LinkSpan for people who might not have the enterprise experience that I have, or for people new to coding who might not yet realize how things can go wrong.

Ever since pagers came about, IT Administrators and Application Developers have been scripting alerts to let them know how their computers, infrastructure, and apps are doing. From pagers, to text pagers, to SMS, to mobile email… sys admins and developers grep log files and pass critical status messages to them so they can stay ahead of problems.

Stay ahead of problems.

Developers usually know when things are about to go off the rails. They simply script some of that knowledge, and use it to alert them so they can fix problems while they can still be resolved without too much bad happening.

Their knowledge, in "service or API terms" can be thought of as "the contract". The contract the developer has with the API they're using. In many cases, the contract is implied, so it's not something you might see articulated anywhere but API documentation. Specifically, how to use an API and what sorts of messages/formats/responses to expect.

The important thing about the contract is that it ends up being specific to the way you're using the interface (in some regard). The API may be up, but your expected results may not be happening in the way you expect (for a variety of reasons). Developers know that up/down isn't what matters (most app/system management tools and teams have that covered very well), and that it's usually a degradation of service that impacts things worst. Even worse, degradation of service is the problem that's most difficult to resolve.

LinkSpan provides an "everyman's scripting engine" for ensuring the contract you expect is the contract you're getting.

Simply connect to the API you're using (or import your custom API), pick the methods you're interface is supporting, then paste in the data format you're app expects. This is all much easier than it sounds, and LinkSpan gives you a simple wizard to walk your through the steps. That test can then be used to raise an alert, or to generate insightful dashboards and reports you can use to track trends and plan future projects.

Now, developers can go about their business, knowing that Facebook, Twitter, or whatever API your app depends on is working according the contract you expect. And, when things start to go sideways, you're the first to know and can take the mitigating actions necessary to prevent the API's "failure" from impacting your users.

Peace of mind. Easy.

Why not try LinkSpan free for 15 days?

The ongoing Oracle vs. Google lawsuit is bringing increased focus on the applicability of copyright laws to software and specifically APIs.  At stake is whether a provider can provide an API that “looks like” another.  While you might have already formed an opinion on this issue, it is a good idea to consider the purposes and objectives of a copyright.

A copyright legally protects works of original authorship fixed in tangible form.  For a similar paradigm I think it is helpful to look at the application of copyrights to websites.  In that case, a copyright can be attained to protect the text, artwork, music and audiovisual material, but it does not protect the ideas, procedures, systems or methods of operation behind that website.  Right away, what this tells me is that copyright laws are for content not process.  APIs are written for applications, not users, so while APIs can deliver content that might fall under copyright laws, the actual delivery mechanism is simply a process.  This of course is where patents come into play which is an entirely different form of protection. 

But lets dig a little deeper and not just dismiss this application of the copyright laws so easily.  Looking at the website paradigm a little more closely, this interpretation of the law means that you can’t publish a website that looks just like http://espn.com.  However, you can publish the scores of different games just like that site does.  The same is true of a site that publishes word definitions just like http://dictionary.com or stock quotes just like http://nasdaq.com. 

This is a great precedent that helps us to draw the line between protecting unique content and overzealously blocking innovation.  Consider the following information:

(21-11)Texas 7, (20-12)Baltimore 3

The fact that two teams played a game, each has a record for the season, and there was a final score for the game is not unique content, which is why I can provide this information in my blog without legal ramifications.   I only start to encroach on copyright laws if I use team logos, other protected graphics, or copy somebody’s summary of the game.  Just as a baseball box score doesn’t differentiate one site from another, an API message’s signature does not differentiate it from another.  The real value is in how the provider retrieves, processes, enhances, and/or formats that data, all of which can be protected through a combination of patent and copyright laws that require no reference to the API signature. 

Imagine the consequences if only one company could provide baseball scores on their website or provide a weather forecast through an API.  This application of the copyright laws would limit innovation and provide a barrier to entry that would lead to domain-specific monopolies.  There is a lot of opportunity to add value through the use of APIs, but blocking new entrants for specific API signature would quickly stifle that opportunity.

Ask any developer what the most boring and frustrating part of programming is and odds are you will hear “testing” come up in the first couple of responses.  While it is rewarding to get through the testing of any code as the final sign of task completion, the process itself can be extremely aggravating and bewildering.  A savvy consulting services shop will allocate just as much time for testing as development and while they often have to defend such an estimate to their clients, that is experience talking not simply a desire to inflate the bill.

The other aspect of testing that makes it very boring is that it is a process that never really ends.  Just because something works correctly today doesn’t mean it will continue working tomorrow.  Not only are their often seemingly harmless code updates that can have undesirable side effects, there are environmental changes that can also have dire consequences.  I’ve seem many scenarios where a change to a router rule or a configuration update would impact entire systems.  The only way to possibly provide assurances that your application is still working as desired is through continuous regression testing. 

Many organizations and developers will simply rely on the ongoing monitoring of real-time activity in lieu of continuous testing but this will often leave holes in a true continuous testing strategy.  However, true continuous regression testing would provide independent verification that the application or system still behaves as originally intended.

This is exactly why automation and testing go so well together to provide a much higher level of assurance.  This has been realized through the many tools available for testing browser-based applications such as Selenium and TestComplete.  At OpusGrid, we this same combination can be just as useful for API providers and consumers.  This is one of the reasons we targeted API testing in the very first release of LinkSpan.  Just as you can record a set of actions in a browser and play them back, LinkSpan allows you to record a specific API call and define a schedule for that to be played back.  Those results can then be captured in a report or used to send alerts.

So if you are custom building your own test system or find yourself frequently testing APIs manually, please take a few minutes to check out our quick walkthrough video to see how Automation and Testing can make your life a little less aggravating.

Day four of Oracle's copyright and patent lawsuit against Google's Android OS brings a lesson in API design and programming that even the judge declares 'confusing.' http://bit.ly/IBHL9N

Ever tried to explain what an API is and does to a loved one, a friend or an investor?  Imagine having to explain what an API is to a jury!  What are your favorite examples of how to explain "What is an API"?

Irregardless of the how much SaaS a company uses, they're still going to have internal systems. To improve integration across internal systems companies will create internal API's. They're already doing so. And, it's becoming cool to do so even more so I think we'll see some acceleration in this space.

Internal API's need to be managed just like external API's. In fact, a good API management solution will integrate on-premise and off-premise API management tools enabling developers to manage API's seamlessly no matter where the API sits.

Mashery has an interesting article about API management that unfortunately tells just half the story. A solution that only lets developers manage external services is incomplete. Internal API's are more likely to be SOAP based than REST based (my own opinion, not a research driven observation). These internal API's will need different management tools/features, but the experience of managing internal and external API's will need to be consistent (and consistently easy to use).

A SaaS API management tool is not going to be allowed access through a company's DMZ to manage internal API's. I'm pretty liberal on security implications of enterprise SaaS deployments, but even I can't see any way something like this is ever going to happen. To properly manage an internal API from a hosted API management tool will require storing your internal API contract on the external host. Way too risky.

You might want to start by managing external API's first to ensure that you're managing the service you're getting from an external provider. But keep the endgame in mind. I believe that over time your internal infrastructure will look a lot like these external ones (if they don't already). You will want to manage contracts between teams the same way you want to manage contracts to your external providers. Doing so will foster an internet-style collaboration model between internal teams, leading to more creativity in how internal systems (and their data) are used by employees (an important and desirable result).

Be careful that you don't find yourself in a situation where you invest in a tool that provides no possible path towards a unified API management experience between external and internal API's. You'll regret it. And, by the time you do, it'll be too late.

As I read about the Instagram acquisition yesterday, I was just as struck as others at how important it was to Facebook to own the user experience of posting and sharing pictures with their friends and family.  In fact, $1B goes beyond important in most people’s minds.  Facebook does a great job of facilitating picture sharing from a computer, but Instagram had leapfrogged them in the mobile device experience which gave them obvious concern. 

5 million pictures a day are uploaded and shared using Instagram.  The most valuable part of that process is the actual sharing which is done through Facebook, Twitter and Tumblr.  What is really interesting to me is that Instagram saw an opportunity to enhance a single process and was able to turn it into a billion dollar asset.  Notice that I said enhance, not build or invent.  Users could already upload and share the very same photos with the very same people.  The innovation was an application that simply made things easier and more enjoyable for the user.   This is why it only took 12 people 2 years to grow Instagram to 30M+ users.

The key to all of this quick growth was APIs.  Instagram was able to build an application that enhanced the user experience without starting from scratch because of the FB, Twitter, and Tumblr APIs.  Because of these APIs, they only had to build out their own photo repository which is a lot easier than building your own social network.  Just ask Google   

Building from scratch is really hard and risky and its usually unnecessary.  The key to quickly enabling a valuable customer experience is to build on top of what already exists and reaching out to existing users if at all possible.  No next gen application is an island and yesterday we saw more evidence of how crucial APIs have become in enabling the next wave of innovation.  Instagram is just the latest example and certainly not the last.

Nuance is a company that's been around for quite some time.

I find it interesting that a change to their API can impact their strategy greatly, yet it appears that will be the case.

In fact, their API strategy is complementing their overall operational execution strategy at the highest levels as Apple appear ready to announce deep Nuance voice integration with the next generation of iPhone.

As with most other activities lately, things are being done faster with fewer people. What better way to understand how your API is being used, so that you can adapt quickly to market signals than to use a tool like theRightAPI for collaboration with your developer community and insight into their activity?

It's crunch time here at OpusGrid. All very exciting (and busy).

So, yesterday Google launched the first Google+ API's. It'll be very interesting to see how it goes. I think there was a bit of a hockey stick adoption to Google+. It seemed to launch great, then adoption seemed to fall off.

I wonder if this was because we were limited to the features and capabilities that Google launched with the first release. Now, with the release of the API we'll see some innovation by outsiders using Google Plus as a platform. This is where the rubber meets the road, and now we'll see if Google+ stands a chance.

I'm interested in seeing if I'm correct, because if I am, it seems that it's no longer OK to launch a product like this without an API. That's some change to proprietary software models which in many ways stifle innovation.

New to Google+? Why not add me to a circle, and let's figure it out together.

Last week I saw an introduction to BuddyPress 1.5. BuddyPress is a WordPress plugin for creating a social community. Like WordPress it's really more of a platform, on which others can add value with plug-ins of their own.

BuddyPress hasn't had a good update in a  while, and the 1.5 release is quite an important one as it turns out.

What I found really interesting was that a large focus of this release is making it a "good community member". Meaning, it integrates much more cleanly with WordPress than in the past. It behaves just like other plugins now - in the past, being a close part of WordPress the developers had taken some short cuts… short cuts that made it harder for other developers to work with.

Why is it so important for BuddyPress to be developer friendly?

Because in today's "game" your value is only partly what you provide out of the box. It's also important for others to be able to innovate on your platform.

While BuddyPress behaved badly, developers were reluctant to innovate because it made their lives more difficult. In particular, BuddyPress used to throw all these unnecessary error/debug messages, so when developers had to debug their own code it was a nightmare. Similarly, developers had little confidence in the quality of BuddyPress itself when their experience developing to it was so difficult.

TheRightAPI is a solution to help developers make sure that their API's are supportive of the community of innovators around them. It's a language for setting and delivering on expectations, so that developers on both sides of the API know exactly how things should work, how they are working, and what's needed in the future.

By the way, if your API is not listed on theRightAPI, let us know please.

Last week I saw an introduction to BuddyPress 1.5. BuddyPress is a WordPress plugin for creating a social community. Like WordPress it's really more of a platform, on which others can add value with plug-ins of their own.

BuddyPress hasn't had a good update in a  while, and the 1.5 release is quite an important one as it turns out.

What I found really interesting was that a large focus of this release is making it a "good community member". Meaning, it integrates much more cleanly with WordPress than in the past. It behaves just like other plugins now - in the past, being a close part of WordPress the developers had taken some short cuts… short cuts that made it harder for other developers to work with.

Why is it so important for BuddyPress to be developer friendly?

Because in today's "game" your value is only partly what you provide out of the box. It's also important for others to be able to innovate on your platform.

While BuddyPress behaved badly, developers were reluctant to innovate because it made their lives more difficult. In particular, BuddyPress used to throw all these unnecessary error/debug messages, so when developers had to debug their own code it was a nightmare. Similarly, developers had little confidence in the quality of BuddyPress itself when their experience developing to it was so difficult.

TheRightAPI is a solution to help developers make sure that their API's are supportive of the community of innovators around them. It's a language for setting and delivering on expectations, so that developers on both sides of the API know exactly how things should work, how they are working, and what's needed in the future.