As the high-profile Oracle-Google Android trial has continued, it has cast light on the changing nature of the application programming interface (API). Oracle Corp., Redwood City, Calif., contends that its Java APIs can be copyrighted. Palo Alto, Calif.-based Google demurs.
The first view recalls the days when big companies only shared APIs as part of complex – and expensive – corporate alliances. The latter view reflects the API ethos of the Internet era, where Web APIs are open and freely shared.
So, the API landscape is changing. This evolution of the open API is front and center in an ongoing shift in the SOA world, one increasingly driven by emphasis on wider use of light-weight JSON and REST services.
The move is reflected further in new ''API management'' products that supplement established SOA governance and management tool sets. Observers note that, although RESTful strategies and APIs seem to be staging a revolution, it is a revolution based on SOA principles and one where there is still room for some more traditional SOA-based approaches.
It may be said that today’s Web APIs more truly reflect the nature of the Web, compared to earlier so-called ''Web services.'' But the Web services and SOA experiences were important ones. James Governor, an industry analyst with RedMonk, says the hard work done by organizations to isolate and encapsulate services is “terribly valuable.” While he admits the original Web services stack has come under considerable scrutiny, he says “it does have value, but not for everybody.”
In his view, the SOA work will maintain its worth because it is always amenable to use in the newer Web technologies, for both development and integration. “The hard work has been done; now we can see how the Web does this.”
''Learning from the API management approaches we are taking from the Web will have a significant impact on enterprises,” he notes. “Everyone is retooling for API management; it is like API management is the new SOA,” he says.
Governor says recently announced API management capabilities from IBM Corp., Armonk, N.Y., means APIs have arrived. [The company discussed IBM Cast Iron Live Web API services earlier this month at IBM Impact 2012.] But other SOA stalwarts such as Layer 7 Technologies, Vancouver, B.C., and SOA Software, Inc., Los Angeles, Calif., had been chanting the API management mantra ahead of Big Blue.
Scott Morrison, CTO and chief architect at Layer 7 Technologies, has seen and participated in the SOA community. Today, he says his company is focused on management and security for APIs and SOA based architectures. “We have been through the whole SOA revolution and what it meant to the new revolution for APIs,” he says. He describes that revolution as “a move toward agility and simplicity and away from complexity and formalization.” The company has added SecureSpan API Proxy, the Layer 7 and the API Portal OAuth Toolkit to its lines of SOA governance and gateway tools.
Another established SOA hand sees a similar trend. “The term 'API' being bandied around the industry today is quite different from the traditional developer API,” said Ian Goldsmith, vice president of product marketing, SOA Software. “As used today it refers to an interface exposed by an application for developers to consume over the network, not a proprietary interface. Today, it is standards based.” Goldsmith’s firm has added Atmosphere API management tools to lines that include its mainstay SOA governance software suite.
Open, public APIs
A key shift has been the culture of openness. “One reason the Web took off was that anybody could be a programmer. You could click `view source’ and see the source code and then you could copy and paste from that model of success,” says Morrison.
“That was a profound shift; the browser world is much more open, it is all about delivering the code as is to the browser and literally allowing people to see how it works,” he adds.
Without that openness, Morrison says computing can be difficult. “When I look at the API revolution it reminds me that when you start from something you can then build more sophisticated capabilities that you could never do in classic SOA.” Morrison says the beauty of the API world is it leverages what’s already been done and doesn’t require you to sit down and install special infrastructure or libraries to do machine-to-machine communication. “In a lot of ways, you can think of it as the web for machine-to-machine communication,” he says.
However, Morrison admits nothing is perfect. In jettisoning more formal SOAP-based and WS file approaches to distributed systems as opposed to RESTful system approach, there can be dangers as the functional problems get more sophisticated.
Security is a good example. Morrison says a great thing that APIs have achieved is they have moved away from a complex approach to security embedded in SOA, which tried to push security down to the messaging level. “They were powerful, but the truth is most people didn’t need that. It was elegant from a design perspective, but it was overkill,” says Morrison.
Indeed, he says, sometimes the solution was so big and complex it became unwieldy and easy to misconfigure, so it created security problems in its own right.
“The API security model says ‘good old SSL is good enough.’ Simple is best for security because there is less to screw up. So, you see a lot of the same benefits around security with API revolutions," he adds.
Another weakness is that right now, in the RESTful world, there is no commonly accepted approach to describe how an API should be defined. Some observers might counter that SOAP, so closely connected to established SOA, was perhaps too thoroughly defined.
This was first published in May 2012