How to Make Open APIs Enterprise Ready

Loraine Lawson
Sep. 17 2012, 02:00PM EDT

Typically, when anyone talks about APIs, they talk about internal or enterprise APIs and external or open APIs. But as the cloud services become more widely adopted, we’ll see an interest in more hybrid situation, where internal IT departments use external APIs or other services as part of a broader architecture.

What does this mean for developers? If developers don’t rethink how they build APIs, it could mean a lot of rework down the road, warns David Linthicum, a cloud computing, SaaS and SOA.

“In my real-world encounters as a consultant, I find service design to be a more haphazard process,” he writes in a recent InfoWorld post. “However, that need not be the case if you understand the use cases and how all these elements should exist in architecture.”

Linthicum suggests developers consider how well their APIs will work in an internal, service-oriented architecture. Right now, most APIs and other public services are simply too fine-grained to work in a larger architectural setting, he warns.

In traditional service-oriented architecture, that means designing for re-use. APIs are services, of course, but developers need to think through how they can design APIs in a way that makes them play well with other services, as well as legacy systems.

“In other words, you need to understand how businesses will employ these services to form real workplace solutions -- inside and outside the enterprise,” Linthicum states.

His advice is high-level and more of a strategic view of what needs to change in API development. If you’re looking for more specific, tactical issues developers need to address before APIs are enterprise-ready, then check out what Corneliu I. Tusnea, architect at OneSaaS, had to say about making APIs easier to integrate.

OneSaaS is a cloud integration company whose job is integrating APIs of all types. In answer to the Quora question, “What are the main obstacles that cause slowness when integrating an API with your product,” Tusnea offered a list of 10 problems he often encounters.

Missing documentation topped the list, and he described undocumented error messages as “the worse offender.” As we shared last month, both rank among the top 10 API worse practice.

But many of the issues Tusnea lists could be particularly problematic in a larger architecture, including:

  • Change management issues, whether it’s requiring a full data set to determine whether there are changes, not including “searches” that would allow you to retrieve all data that’s changed since a specific time or entities that require two calls to determine if anything’s changed.
  • Unspecified time zones
  • Inconsistencies, whether it’s inconsistent names, data-time formats, xml formats

Enterprise IT is still “of setting individual developers loose to register and start using APIs without any client-side governance of this activity,” writes Jamie Ryan, Partner Architect at Layer 7 Technologies, in a recent ProgrammableWeb guest post.

But clearly that’s not the only issue developers need to address before open APIs are ready for deployment as part of a hybrid architecture.

To learn more, explore our list of APIs designed specifically for the enterprise.

Loraine Lawson Loraine Lawson is a freelance technology journalist specializing in covering data, all things integration — including APIs— and B2B supply chain management issues. She's been writing online since the days of hand-coded HTML pages. Lawson was a newspaper journalist but managed to jump ship just before "print journalism" made the endangered species list. Now she works almost exclusively online while managing a toddler, preteen and a really annoying but somehow lovable miniature Schnauzer/Jack Russell mix. The plants, who didn't complain, are now resting in peace.

Comments

User HTML

  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.