Welcome!

SDN Journal Authors: Liz McMillan, Yeshim Deniz, Elizabeth White, Pat Romanski, TJ Randall

Related Topics: @CloudExpo, Java IoT, Microservices Expo, Cloud Security, @DXWorldExpo, 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 a leading IT industry analyst, Forbes contributor, keynote speaker, and globally recognized expert on multiple disruptive trends in enterprise technology and digital transformation. He is ranked #5 on Onalytica’s list of top Digital Transformation influencers for 2018 and #15 on Jax’s list of top DevOps influencers for 2017, the only person to appear on both lists.

As founder and president of Agile Digital Transformation analyst firm Intellyx, he advises, writes, and speaks on a diverse set of topics, including digital transformation, artificial intelligence, cloud computing, devops, big data/analytics, cybersecurity, blockchain/bitcoin/cryptocurrency, no-code/low-code platforms and tools, organizational transformation, internet of things, enterprise architecture, SD-WAN/SDX, mainframes, hybrid IT, and legacy transformation, among other topics.

Mr. Bloomberg’s articles in Forbes are often viewed by more than 100,000 readers. During his career, he has published over 1,200 articles (over 200 for Forbes alone), spoken at over 400 conferences and webinars, and he has been quoted in the press and blogosphere over 2,000 times.

Mr. Bloomberg is the author or coauthor of four books: The Agile Architecture Revolution (Wiley, 2013), Service Orient or Be Doomed! How Service Orientation Will Change Your Business (Wiley, 2006), XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996). His next book, Agile Digital Transformation, is due within the next year.

At SOA-focused industry analyst firm ZapThink from 2001 to 2013, Mr. Bloomberg created and delivered the Licensed ZapThink Architect (LZA) Service-Oriented Architecture (SOA) course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, which was acquired by Dovel Technologies in 2011.

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), and several software and web development positions.

CloudEXPO Stories
Sanjeev Sharma Joins November 11-13, 2018 @DevOpsSummit at @CloudEXPO New York Faculty. Sanjeev Sharma is an internationally known DevOps and Cloud Transformation thought leader, technology executive, and author. Sanjeev's industry experience includes tenures as CTO, Technical Sales leader, and Cloud Architect leader. As an IBM Distinguished Engineer, Sanjeev is recognized at the highest levels of IBM's core of technical leaders.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a member of the Society of Information Management (SIM) Atlanta Chapter. She received a Business and Economics degree with a minor in Computer Science from St. Andrews Presbyterian University (Laurinburg, North Carolina). She resides in metro-Atlanta (Georgia).
We are in a digital age however when one looks for their dream home, the mortgage process can take as long as 60 days to complete. Not what we expect in a time where processes are known to take place swiftly and seamlessly. Mortgages businesses are facing the heat and are in immediate need of upgrading their operating model to reduce costs, decrease the processing time and enhance the customer experience. Therefore, providers are exploring multiple ways of tapping emerging technologies to solve this industry problem. During this session, Chander Damodaran, Chief Blockchain Architect at Brillio Technologies, will discuss how blockchain could transform the mortgage business and its value chain. Blockchain can bridge the gap and provide a seamless digital channel to enable quicker and transparent mortgage processing thereby elevating the overall experience and helping drive costs down.
This session describes how Professional Services organisations can deliver within Technology-as-a-Service (IaaS) constructs, in private and public enterprise cloud scenarios. See how professional services can be packaged and funded by IaaS cash flows, based upon consumption of technology services. Learn how significant, IT infrastructure transformations can be funded through OPEX spending models with multi-year As-a-Services based contracts. Understand how the automation of repeatable services can positively impact the commercial viability of Professional Services within As-a-Service constructs. Hear how innovative IT infrastructure service offerings can elevate the impact of professional services engagements, and accelerate positive business outcomes.
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and European perspective.