REST and what's next

The adoption of REST as the developer's tool of choice for communication has been getting plenty of press over the past few years. At xTuple we're on board. We've built our Web/mobile cloud ERP solution with a REST server baked into the very way that our own client communicates with the server. It was a priority of ours to have the moving pieces of our system be able to talk with the same standard that could be used by any other system, such as our own B2B or B2C Web Portal, external Business Intelligence suites, or anything else.

REST and JSON were the obvious choice, because of their ease of use, and because they work natively with our full JavaScript stack.

But let's not be too triumphalist about REST. Just as REST is enjoying its day in the sun, at xTuple we're already deep into the technology that is starting to supplant it: WebSockets. Strangely enough, WebSockets is a reversal of the trend to simplify protocols. WebSockets requires a custom specification, just like the now-reviled SOAP did. Still, technologists are adopting it because of its power as a low-overhead, low-latency, two-way communication stream.

Part of the reason that we've been able to build our Web/mobile client to be faster than our desktop app is that we leverage brief, frequent dialog between your device and our server. When you pull up a list of all your CRM contacts, for example, the app only pulls the first screenful of data across the wire. All the rest of the contacts are lazy-loaded as you scroll down the list. WebSockets are so fast that the pause is unnoticeable even though many requests are being serviced every second.

The other great feature of WebSockets is that it allows the server to push data to the client without a request. With AJAX the most common way for browsers to receive notification from the server was to poll it every few seconds. "Any news for me? How about now? How about now?" With WebSockets we can keep open a two-way line between the client and the server. 

How might this be useful? Let's say someone else at your organization has just made an edit to a record you have open. We'll be able to notify your app immediately that the data has gone stale and prompt a refresh. This is something that AJAX/REST wasn't built to do.

But for everyone thinking about using REST to integrate xTuple with your other solutions, our keenness for WebSockets is no threat. We support REST and always will, and since our WebSockets server and REST server are built on the same query engine, they will always work in parallel. In fact, we're right now building out an API Discovery Service modeled on Google's and implementing OAUTH authentication to keep our REST server at the cutting edge of what's possible.