Web 2.0 Application Development Takes a REST

By: Paula Bernier

In an effort to facilitate service creation and modification on telco networks in “Internet time”, telephone companies and their suppliers have in recent years have created APIs to avail their networks to the Web 2.0 developer community. Originally, these efforts centered on Web services. But the Web services model has taken a backseat to REST.

REST, which stands for representational state transfer, is a programming methodology that borrows heavily from Java, explains Neil Weldon, director of technology at Dialogic (News - Alert) Corp.

“Web services are often higher-level C constructs, which are exposed through HTML,” says Weldon. “What RESTful APIs may do is stateless, and oftentimes there’s a database type of functionality that lies behind them. Like if I write in AJAX, for example, there may be a database [that] maps or correlates to that API to something more complex, which sits behind it.”

Web services and REST are very similar, continues Weldon, who sees the battle between the two as a religious war more than anything else. But, he adds, it could be argued that the latter is a bit more simple and familiar to a greater number of programmers. For example, he says, Facebook (News - Alert) uses a Web 2.0 RESTful-style API to enable developers to create applications for the wildly popular social networking site.

“REST is in vogue, it’s the way to write an API or develop an SOA-type of functionality,” says Weldon.

“A lot of the newer talent [that] is coming out in the industry today, especially people who are more Java-based, would probably lean more toward the Web 2.0 API structures,” he adds. “I’d hate to call the Web services people old school, because they’re certainly not old compared to C language or even lower constructs.”

However, he explains, Web services was more popular five or six years ago, just after it was established, than it is now.

As evidence of the new-found popularity of REST in both developer and telco circles, Jim McEachern, manager of application enabler standards at Nortel (News - Alert), recently told INTERNET TELEPHONY that the service-oriented network effort under way at the Alliance for Telecommunications Industry Solutions is now considering how to bring REST into the fold.

McEachern considers REST a simpler method of Web 2.0 application creation and says that the bulk of development these days involves RESTful interfaces. However, because REST lacks the ability to convey stateful information, the ATIS (News - Alert) group is looking at “a middle ground” called REST RPC, or remote procedure call. REST RPC uses the basic mechanism of REST but adds to the mix some of the state, complexity and richness of Web services. (For more on the ATIS SON effort, see the February INTERNET TELEPHONY article headlined “Bridging Legacy, Next-Generation Networks: Catalyst, SON, Other Efforts Aim to Span the Divide.”)

Yet more evidence of the new prominence of REST is that Dialogic is creating RESTful APIs to enable Web developers to build telephony-related applications.

“Most Web programmers today, they really don’t understand the call control, signaling, call state involved in telephony,” says Weldon, adding that call hold with music, for example, is a particular call state. “That’s a pretty complex thing to write in C code, and often the signaling involved in that is beyond comprehension of most Web programmers.

“So Dialogic is establishing a set of APIs, which are well known to Web 2.0 programmers, and have to do with essentially a stateless API known as a RESTful API.”

RESTful APIs address developers using AJAX, which was referenced above, as well as a wide variety of other REST frameworks, including but by no means limited to PHP and Ruby on Rails.

“Everybody seems to have their own favorite API,” notes Weldon. “There is one drawback to Web 2.0 APIs -- I would say there are too many of them, and everybody likes their own favorite one. So what Dialogic is doing to address that is we’re doing all the underpinnings and the foundation and exposing a very simple interface. It’s like four-function interface, [and] anyone can bolt their own flavor of Web 2.0 APIs on top of that. In many ways it’s a Web services approach. So Web services lies at a layer below RESTful APIs.”

As explained earlier, this hybrid kind of approach is important given that REST does not acknowledge state.

Because there’s no state reserved with REST, Weldon explains, “if I were to query the function, which in a RESTful sense, there would be no response back telling me what state I’m in. It’s always being renewed – you’re on hold, you’re on hold, you’re on hold, you’re on hold. It’s always fresh.”

So Dialogic in its new APIs created four functions -- put, get, post and delete -- that can be directly matched to database constructs.

“Many programs are based on SQL databases,” he continues. “And I can affect a SQL database with four simple commands: insert, select, update and delete, which map to put, get, post and delete.”

Weldon says service providers might want to adopt this kind of construct for developers, and then deploy a session controller type of device in their networks to mediate between the application cloud and their services, similar to how some of today’s service delivery platforms handle conversions between Parlay and Parlay X, or between SIGTRAN and SS7 or SIP. IT

» Internet Telephony Magazine Table of Contents