"You keep using that word. I do not think it means what you think it means"

In keeping with what a great swordsman once uttered, using that word wrong doesn't make your web service work better. The Application Programming Interface (API) in Service Oriented Architecture (SOA) is a new catch phrase, we hear. This so-called 'REST API' is almost always just an 'HTTP interface' given a fancy name to make it sound better, more so than the integration strategy many consultants are offering up. In an organization with an e-commerce or web development team, this "programmer" view makes SOA seem cool.

REST stands for Representational State Transfer, as proposed in a doctorate dissertation. This approach uses the four HTTP methods GET, POST, PUT and DELETE to execute different operations, compared to SOAP, which creates new arbitrary commands (verbs) like getAccounts() or applyDiscount(). Thus, a REST API is a set of operations that can be invoked by means of any the four verbs, using the actual URI as parameters for a web service operation. For example, we might have a method to query all case management accounts which can be called from /accounts/all/ to invoke a HTTP GET and the 'all' parameter. This tell the web service that to return all accounts, probably in an XML stream annotated for the particular client (with CSS, for example, for a browser).

Here at Bluedog, our apps have always been built with the web tier against the same set of "APIs" as the mobile tier. The advantage of a Java/WebObjects framework is "out-of-the-box" support for a variety of clients. The Ajax framework in Project Wonder provides many of the features that Rails users have come to expect, but written in a style that fits well with "The WebObjects Way" of doing things. An attempt is made to avoid writing javascript whenever feasible, as well as providing as much support for component actions as possible.

The majority of Ajax framework is written without dependencies on ERExtensions (the core framework in Project Wonder). This means that for most Ajax capabilities (the JavaScript/CSS components that give sizzle to the browser), we can use a framework without making a Web Service or Application extend any classes. Advanced capabilities can be designed using supporting classes that are available in the ERExtensions framework or by extending the open source classes such as ERXSession in our foundation frameworks.

The rise of mobile has harkened back the older client/server model which emphasized rich client interfaces, first made popular with Swing and other attempts at native Java clients. With our "API-first" development model, the Java/WebObjects tier is the interface to the device -- or client. When you put a desktop browser client, mobile native app (Objective C for iPhone or iPad) or a desktop app in front of the app server you make a mobile-enabled stack is simple. And all is right, in the world of SOA.