REST/WOA - Customer Relationship Management

Interestingly enough, there is another architecture that hearkens back to a simpler day when men were hunters and women tended to the fields and wash . . . oh, wait, that’s the Neanderthals of the Middle Paleolithic Era, not IT architecture. Wrong tool set.

Actually, I’m talking about representational state transfer (REST), also inter- changeably (if not accurately) called web-oriented architecture (WOA). There is one major CRM—actually enterprise applications—vendor who uses it really well. That would be Sage Software (see below) who has always varied from the norm when it came to architectures. REST is an interesting and important choice, and, I would venture to say, might even be the architecture of choice if you’re a small or lower-end midsized business. It’s worth more than a look—it’s worth an investigation.

What Is REST?
REST is what I’d like to be doing at the moment I’m writing this. I can’t because I’m too busy, but I can tell you about the value and the pitfalls of REST architecture.

Simply stated, REST is a web services architecture that has one and only one interface—one that is based on HTTP, meaning a classic web browser. Application-specific interfaces are taboo, which is, of course, where it differs from SOA. There are only four command states that apply—Get, Post, Put, Delete. Essentially, it’s the same architecture that runs the Internet, and the one you use when you fire up Internet Explorer (or Firefox or Safari or any browser you use), type in a URL, and hit Enter. By the way, that would be Get in REST command lingo.

Representational State Transfer (REST)
REST emerged from what is now a geek-legendary doctoral thesis called “Architectural Styles and the Design of Network-Based Software Architectures, ” by Roy Fielding, at the University of California, Irvine, in 2000. Fielding, now the chief scientist at Day Software, figured out how to use the standard Internet protocols to interact with data.

There were only four basic commands (Get, Post, Put, and Delete) and one basic interface—a web browser—and that was the extent of it. The idea was that the URL was the equivalent of a noun, as Ryan Tomayko explained it in his posting, “How I Explained REST to My Wife.”

Tomayko’s explanation, as gender uncomfortable as it might be, is actually pretty good, whether you’re female or male. HTTP is a protocol that is used to “describe the location of something anywhere in the world from anywhere in the world.” That location is the URL. What Get, Post, Put, and Delete provide are the verbs in this schema. These are the universally possible actions that can be read by any machine in any format from any operating system. For example, if you wanted to read my ZDNET blog, you would type in the URL and hit the Enter key on your PC or Blackberry and up would pop my blog’s latest entry, which is a representation of the web page. The reason that it’s a representation is because the web page is being reproduced in multiple other locations at the same time. If there was only the “original, ”no one would see it but the first person to access the URL. But there really is no original resource. There are only representations of the resource. That would be, according to Tomayko, the noun.

Got that so far?
Then there are the four Tomayko-labeled verbs. Get, Post, Put, and Delete are universally applicable to any machine. They represent the same thing regardless of platform, operating system, or hardware used—a condition called stateless. This is very much like SOA, also stateless. But, unlike SOA, those four commands are the only ones REST uses when it does something. So if you wanted to access a small section of a web page, there would be HTTP GETs going on until all the necessary representations to identify that web page segment were made available to you.

REST is secure with SSL (Secure Sockets Layer) and HTTPS, so there is no question of its ability to protect necessarily private information.

What makes it powerful is that it’s simple. And because it is a wellknown standard already adopted by anyone who writes for or uses the Internet, it gives developers more control over how they create access to its functions. In fact, according to a 2008 tutorial on REST from SearchCRM, when comparing SOAP to REST (no, not bathing to sleeping), 80 percent of developers preferred REST.

Let’s take a look at REST in a CRM system
REST as applied to a CRM system

REST, in this figure, consists of three layers: the interface with its URL, the four verbs, and (when it comes to interacting with data) the XML payload—the same XML that SOA uses. This makes interoperability with SOA possible.

In fact, there are vendors who have come out with RESTful APIs that are normally designed to pass messages back and forth between REST and SOA architectures. Table outlines a few of them.
Table: A Sampling of Vendors with RESTful APIs
A Sampling of Vendors with RESTful APIs

Data-Centric vs. Remote Procedure Call
One major difference between REST and SOA is that REST is datacentric while SOA is dependent on remote procedure calls (RPCs). What that means in nearly practical terms is that REST is data-centric and SOAP, which relies on RPCs, is process-centric.

What that means in totally practical terms is that the developer who uses SOA and SOAP for remote procedure calls is building an interface onto a specific application that does specific things. He then is giving the user access to the interface and the associated commands so that the user can use the application in the way it was created. For this, there are an unlimited number of verbs.

REST, with its data-centric model, is emulating the Web. So the four verbs that apply to the Web and its interface are what REST uses for information gathering and passing. By passing an XML document, the URL does the work to get the information that provides the variability of the applications.

So who does REST well in CRM? Time for the envelope, please.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Customer Relationship Management Topics