How can I make my enterprise applications available to mashups without putting my infrastructure at risk?
First, you should realize that your applications might already be providing the raw materials for mashups. Many mashups consume existing RSS feeds, or liberate XML and JSON data from the underlying URLs that build your web pages. Plus there are also tools that can impersonate a user’s browser and extract information directly from a site’s interface using techniques reminiscent to the old “screen scrapers” that helped modernize old mainframe applications.
Since developers can already sneak in the window to get to this information, why not open the door and let them in? I’ve heard a number of arguments for closed systems. Among others is the concern that if you provide an API for anyone to use, it could create an unknown number of external dependencies. The fear is that you won’t be able to upgrade your application out of fear that you’ll be breaking some other systems that you don’t even know about.
This argument gets a little more traction than others. It’s true that you want other teams to use your API, but that doesn’t mean that you have to cede control over how this usage occurs. In fact, if you design your API correctly, you should be able to accomplish 3 things:
- Your application is amenable to mashup development
- Your API prevents the current infrastructure from being overloaded
- You have a record of who is leveraging your API
If you could achieve these things, you would see your application extended beyond its original goal; it would be both a product and a utility. For some apps (Google Maps and Twitter come to mind) the “utility” aspect almost surpassed the original product once a public API was available. This ability to grow and retain market share by levering an external community is why APIs are baked into most Web startups from Day 1.
I’ve always considered building an API to be one of the most challenging aspects of software development, partly because you have to envision how the API will be used without knowing what will actually be built with it. Your functions need to be consistent and complementary – and stable. You won’t encourage adoption if you keep changing how the API works.
Use the API yourself. That’s the easiest way to spot inconsistencies.
The worst thing you can do is expose the raw interface used internally by your application. This hampers your ability to upgrade, and probably forces developers to learn much more about your system than they want to. Keep functions fairly granular, with very simple functionality. Don’t try to overload a handful of functions with multiple options and configuration switches to do everything under the sun. And use the API yourself. That’s the easiest way to spot inconsistencies.
Consider the best way to expose your API. Is a Java JAR file, a SOAP interface, or a REST API the best solution? Do you return XML or JSON? You might experiment with a limited number of simple functions using different techniques and see which ones become the most popular.
Make developers register for an “API Key”, and make sure they have to provide it on each API call. This lets you track who is using the API and what features are the most popular. It also lets you send out advance alerts if you need to make a change.
Consider adding metering to your API. Once you have the ability to tie API activity to specific people, you can add daily limits to the number of times API methods can be invoked. This will keep your current product from being overwhelmed with requests. Plus, you now have information to take back to other teams when you need to have a discussion about funding upgraded infrastructure.
Lastly, if you take a closer look at APIs that you already find useful, you’ll probably get a lot of additional ideas on what to incorporate into your own design. As I mentioned, designing and API is one of the most challenging tasks in software development, but I also think it’s one of the most rewarding ones. Once you see your API being used to power new solutions, I’m sure you’ll agree.
Dig Deeper on Topics Archive
Related Q&A from Michael Ogrinz
There are scenarios where HTML5 is better than native applications. Expert Michael Ogrinz discusses best uses for each. Continue Reading
Mike Ogrinz says risk-taking is part of software innovation. There should be 'potential for failure,' a key ingredient to innovation. Continue Reading
Before building out a new enterprise portal application, you should probably examine existing systems to make sure they don't need to be ... Continue Reading