Welcome!

Agile Computing Authors: Elizabeth White, Liz McMillan, JP Morgenthal, Yeshim Deniz, Janakiram MSV

Related Topics: @CloudExpo, Java IoT, Microservices Expo, Cloud Security, @BigDataExpo, SDN Journal

@CloudExpo: Article

Bringing Intelligence to REST

The API Economy has nearly run its course.

Whether you're a Cloud Computing aficionado, an enterprise integration specialist, or an IT executive, it's hard to have a conversation today without mention of REST. Representational State Transfer, or REST to the cognoscenti, is an architectural style that treats distributed computing problems as though they were Web problems. On the Web you have browsers chatting via HTTP to Web servers, and those servers can work whatever magic they need to in order to serve up the full wealth we've all come to expect from the World Wide Web. Take those basic Web patterns, extend them to general distributed computing problems (including Cloud and legacy integration), and voila! You have REST.

However, while REST has achieved substantial success in simplifying software interfaces and thus facilitating many forms of integration, it is still inherently inflexible. What works well for humans using browsers often doesn't apply to arbitrary software clients. And most fundamentally, REST does not address the most difficult distributed computing challenge of all: how to deal with dynamic business context.

Freeing Ourselves from REST's Four Constraints
The majority of RESTafarians, as the aforementioned cognoscenti have so eloquently dubbed themselves, treat REST as an Application Programming Interface (API) style. After all, REST does call for a uniform interface, a requirement that in one fell swoop addresses many of the knottier problems of Web Services and other, more tightly coupled API styles that came before. Compared to the complexities of Web Service operations or object-oriented remote method calls, REST's uniform interface is the essence of simplicity. Furthermore, there's no question that REST's uniform interface requirement is at the heart of what analysts like to refer to as the API Economy.

But there is more to REST than a uniform interface. In fact, REST isn't an API style at all. It's an architectural style. As an architectural style, REST consists of a set of constraints on software architecture. In other words, feel free to follow what architectural rules you like, but if you want to follow REST you must comply with the following RESTful constraints:

  1. Separation of resources from representations
  2. Manipulation of resources by representations
  3. Self-descriptive messages
  4. Hypermedia as the engine of application state, or HATEOAS

Let's take a quick tour of these constraints to put them in plain language. In so doing, we'll also why REST fails to adequately address the problem of dynamic business context.

The first constraint is essentially the encapsulation requirement. Resources are abstractions of capabilities on a server, while the representations are what the resources provide to the client. For example, a resource might be a php script running on a Web server, and the representation might be an HTML file it returns when a browser makes a GET request of it. But the browser never, ever gets the php itself; it only sees the HTML. The php is forever hidden from view.

The second constraint calls for the uniform interface. The only way that clients are able to interact with resources is by following hyperlinks in representations - in other words, making GET, POST, PUT, or DELETE requests to the URI of the resource, assuming we're using HTTP as our transport protocol, which we usually are.

The third, self-descriptive message constraint is actually quite straightforward: all the data as well as all the metadata the resource needs to process a request must be contained in that request, and correspondingly, the resource must send all necessary metadata in the representation response to the client that the client will need to understand the representation. In other words, REST requires that there be no out-of-band metadata: information pertinent to the interaction that doesn't actually appear in the interaction. Furthermore, the interaction must be stateless: the resource isn't expected to keep track of any information pertinent to any particular client.

The problem with this third constraint, of course, is that out-of-band metadata is very handy in many situations. Take security-related metadata, for example. REST calls for all such metadata to be in every request, which led to the development of the OAuth (Open Authorization) standard. Yes, OAuth is quite powerful and Web friendly. Yes, OAuth is making inroads into the enterprise. But do you really want to restrict the security protocols for all of your interactions to OAuth and nothing but OAuth? Probably not.

If you have a more complex interaction than a simple request, then the ban on out-of-band metadata becomes increasingly impractical. For example, let's say you're trying to support a complex business process by building a composite application. You're trying to follow REST so you're composing resources. But then you find you need to somehow deal with a range of policies, business rules, or other out-of-band metadata that impact the behavior of your composite application for certain users but not others. REST alone simply doesn't deal well with such complexities.

And then there's the fourth constraint: the dreaded HATEOAS. REST separates state information into two types: resource state and application state. Resource state is shared or persisted state information on the server, while application state is specific to the individual client, who negotiates the application (think abstracted Web site) by following hyperlinks. The HATEOAS constraint hammers home the fact that the point of REST is building distributed hypermedia systems, where the client is responsible for running hypermedia-based applications. In other words, the hypermedia contain the business context for the interactions between client and server.

Hypermedia drive the Web, of course, but once you start breaking down REST's notions of client and server, however, then the power of hypermedia starts to wane. After all, enterprises often want to build or leverage business applications that offer more than a simple Web site, especially when there's a shared business context across nodes, where those nodes are more than just clients and servers. Hypermedia - and REST - simply weren't built for such complex, dynamic situations.

The Devil in the Details
There's a very good reason why REST eschews out-of-band metadata and shared business context beyond the scope of hypermedia: both of these requirements are inherently dynamic, and furthermore, depend upon multiple actors - actors who may change over time. By constraining the architecture to avoid such complexities, REST provides a useful set of simplifications that have provided unquestionable value throughout the API economy.

The challenges in the section above, however, go well beyond REST. The problems we're discussing have plagued software interfaces in general, from the earliest screen-scraping programs to object-oriented APIs to Web Services to today's RESTful APIs. The entire notion of a software interface is an agreement between the people building the software provider and consumer endpoints that the interface behaves a particular way. Loose coupling, after all, relies upon an interface contract that fixes the behavior of the API so that the parties involved can make various decisions about their software under the covers without breaking the interaction. But woe to those who dare to change the contract, or who want to consider metadata the contract knows nothing about!

Out-of-band metadata and business context outside hypermedia applications are by definition exterior to the contract, and thus aren't amenable to any distributed computing architectural style that relies too heavily on static APIs. Therein lies the essential challenge of the API. To those analysts trumpeting the API Economy I say: the API Economy has nearly run its course. We've solved as many problems as we're going to solve with contracted software interfaces. But the business stakeholders still aren't happy. After all, it's their context - the business context - that APIs (whether RESTful or not) are so woefully unable to deal with. It's time for another approach.

The EnterpriseWeb Take
I'm not saying that we don't need APIs, of course, or that REST doesn't serve a useful purpose. I am declaring, however, that something critically important is missing from this picture. APIs are far too static to address issues of dynamic business context. We tried to address these issues with the SOA intermediary (typically an ESB), where the intermediary executed policy-based routing and transformation rules to abstract a set of inflexible Service interfaces, thus providing the illusion of flexibility, much as a flip deck provides the illusion of motion. But even the most successful implementers of SOA were still unable to deal with most out-of-band metadata - and dynamic business context? That nut no one has been able to crack.

What we really need is an entirely different kind of intermediary. A smarter intermediary that knows how to deal with all types of metadata and furthermore, can resolve the more difficult challenge of business context - in real time, where the business lives. In the next issue of Loosely-Coupled I'll discuss how such a smarter intermediary might actually work. And naturally, if you want to see one in action, drop us a line.

Image credit: lin440315

More Stories By Jason Bloomberg

Jason Bloomberg is the leading expert on architecting agility for the enterprise. As president of Intellyx, Mr. Bloomberg brings his years of thought leadership in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture to a global clientele of business executives, architects, software vendors, and Cloud service providers looking to achieve technology-enabled business agility across their organizations and for their customers. His latest book, The Agile Architecture Revolution (John Wiley & Sons, 2013), sets the stage for Mr. Bloomberg’s groundbreaking Agile Architecture vision.

Mr. Bloomberg is perhaps best known for his twelve years at ZapThink, where he created and delivered the Licensed ZapThink Architect (LZA) SOA course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in 2011. He now runs the successor to the LZA program, the Bloomberg Agile Architecture Course, around the world.

Mr. Bloomberg is a frequent conference speaker and prolific writer. He has published over 500 articles, spoken at over 300 conferences, Webinars, and other events, and has been quoted in the press over 1,400 times as the leading expert on agile approaches to architecture in the enterprise.

Mr. Bloomberg’s previous book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business (John Wiley & Sons, 2006, coauthored with Ron Schmelzer), is recognized as the leading business book on Service Orientation. He also co-authored the books XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996).

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting).

@ThingsExpo Stories
What are the new priorities for the connected business? First: businesses need to think differently about the types of connections they will need to make – these span well beyond the traditional app to app into more modern forms of integration including SaaS integrations, mobile integrations, APIs, device integration and Big Data integration. It’s important these are unified together vs. doing them all piecemeal. Second, these types of connections need to be simple to design, adapt and configure...
Microservices are a very exciting architectural approach that many organizations are looking to as a way to accelerate innovation. Microservices promise to allow teams to move away from monolithic "ball of mud" systems, but the reality is that, in the vast majority of organizations, different projects and technologies will continue to be developed at different speeds. How to handle the dependencies between these disparate systems with different iteration cycles? Consider the "canoncial problem" ...
“We're a global managed hosting provider. Our core customer set is a U.S.-based customer that is looking to go global,” explained Adam Rogers, Managing Director at ANEXIA, in this SYS-CON.tv interview at 18th Cloud Expo, held June 7-9, 2016, at the Javits Center in New York City, NY.
Web Real-Time Communication APIs have quickly revolutionized what browsers are capable of. In addition to video and audio streams, we can now bi-directionally send arbitrary data over WebRTC's PeerConnection Data Channels. With the advent of Progressive Web Apps and new hardware APIs such as WebBluetooh and WebUSB, we can finally enable users to stitch together the Internet of Things directly from their browsers while communicating privately and securely in a decentralized way.
"Matrix is an ambitious open standard and implementation that's set up to break down the fragmentation problems that exist in IP messaging and VoIP communication," explained John Woolf, Technical Evangelist at Matrix, in this SYS-CON.tv interview at @ThingsExpo, held Nov 4–6, 2014, at the Santa Clara Convention Center in Santa Clara, CA.
"A lot of times people will come to us and have a very diverse set of requirements or very customized need and we'll help them to implement it in a fashion that you can't just buy off of the shelf," explained Nick Rose, CTO of Enzu, in this SYS-CON.tv interview at 18th Cloud Expo, held June 7-9, 2016, at the Javits Center in New York City, NY.
Web Real-Time Communication APIs have quickly revolutionized what browsers are capable of. In addition to video and audio streams, we can now bi-directionally send arbitrary data over WebRTC's PeerConnection Data Channels. With the advent of Progressive Web Apps and new hardware APIs such as WebBluetooh and WebUSB, we can finally enable users to stitch together the Internet of Things directly from their browsers while communicating privately and securely in a decentralized way.
Who are you? How do you introduce yourself? Do you use a name, or do you greet a friend by the last four digits of his social security number? Assuming you don’t, why are we content to associate our identity with 10 random digits assigned by our phone company? Identity is an issue that affects everyone, but as individuals we don’t spend a lot of time thinking about it. In his session at @ThingsExpo, Ben Klang, Founder & President of Mojo Lingo, discussed the impact of technology on identity. Sho...
"Operations is sort of the maturation of cloud utilization and the move to the cloud," explained Steve Anderson, Product Manager for BMC’s Cloud Lifecycle Management, in this SYS-CON.tv interview at 18th Cloud Expo, held June 7-9, 2016, at the Javits Center in New York City, NY.
"I think that everyone recognizes that for IoT to really realize its full potential and value that it is about creating ecosystems and marketplaces and that no single vendor is able to support what is required," explained Esmeralda Swartz, VP, Marketing Enterprise and Cloud at Ericsson, in this SYS-CON.tv interview at @ThingsExpo, held June 7-9, 2016, at the Javits Center in New York City, NY.
The buzz continues for cloud, data analytics and the Internet of Things (IoT) and their collective impact across all industries. But a new conversation is emerging - how do companies use industry disruption and technology enablers to lead in markets undergoing change, uncertainty and ambiguity? Organizations of all sizes need to evolve and transform, often under massive pressure, as industry lines blur and merge and traditional business models are assaulted and turned upside down. In this new da...
Bert Loomis was a visionary. This general session will highlight how Bert Loomis and people like him inspire us to build great things with small inventions. In their general session at 19th Cloud Expo, Harold Hannon, Architect at IBM Bluemix, and Michael O'Neill, Strategic Business Development at Nvidia, discussed the accelerating pace of AI development and how IBM Cloud and NVIDIA are partnering to bring AI capabilities to "every day," on-demand. They also reviewed two "free infrastructure" pr...
With major technology companies and startups seriously embracing IoT strategies, now is the perfect time to attend @ThingsExpo 2016 in New York. Learn what is going on, contribute to the discussions, and ensure that your enterprise is as "IoT-Ready" as it can be! Internet of @ThingsExpo, taking place June 6-8, 2017, at the Javits Center in New York City, New York, is co-located with 20th Cloud Expo and will feature technical sessions from a rock star conference faculty and the leading industry p...
It is one thing to build single industrial IoT applications, but what will it take to build the Smart Cities and truly society changing applications of the future? The technology won’t be the problem, it will be the number of parties that need to work together and be aligned in their motivation to succeed. In his Day 2 Keynote at @ThingsExpo, Henrik Kenani Dahlgren, Portfolio Marketing Manager at Ericsson, discussed how to plan to cooperate, partner, and form lasting all-star teams to change the...
SYS-CON Events announced today that delaPlex will exhibit at SYS-CON's @CloudExpo, which will take place on June 6-8, 2017, at the Javits Center in New York City, NY. delaPlex pioneered Software Development as a Service (SDaaS), which provides scalable resources to build, test, and deploy software. It’s a fast and more reliable way to develop a new product or expand your in-house team.
SYS-CON Events announced today that IoT Now has been named “Media Sponsor” of SYS-CON's 20th International Cloud Expo, which will take place on June 6–8, 2017, at the Javits Center in New York City, NY. IoT Now explores the evolving opportunities and challenges facing CSPs, and it passes on some lessons learned from those who have taken the first steps in next-gen IoT services.
SYS-CON Events announced today that WineSOFT will exhibit at SYS-CON's 20th International Cloud Expo®, which will take place on June 6-8, 2017, at the Javits Center in New York City, NY. Based in Seoul and Irvine, WineSOFT is an innovative software house focusing on internet infrastructure solutions. The venture started as a bootstrap start-up in 2010 by focusing on making the internet faster and more powerful. WineSOFT’s knowledge is based on the expertise of TCP/IP, VPN, SSL, peer-to-peer, mob...
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
The Internet of Things can drive efficiency for airlines and airports. In their session at @ThingsExpo, Shyam Varan Nath, Principal Architect with GE, and Sudip Majumder, senior director of development at Oracle, discussed the technical details of the connected airline baggage and related social media solutions. These IoT applications will enhance travelers' journey experience and drive efficiency for the airlines and the airports.
With billions of sensors deployed worldwide, the amount of machine-generated data will soon exceed what our networks can handle. But consumers and businesses will expect seamless experiences and real-time responsiveness. What does this mean for IoT devices and the infrastructure that supports them? More of the data will need to be handled at - or closer to - the devices themselves.