Welcome!

Java IoT Authors: Liz McMillan, Yeshim Deniz, Elizabeth White, Zakia Bouachraoui, Pat Romanski

Related Topics: Microservices Expo, Java IoT

Microservices Expo: Article

The Right End of REST

REST is all about distributed hypermedia applications. They’re the point of REST.

One of our Licensed ZapThink Architects, Michael Poulin, struggled with our recent ZapFlash, Where is the SOA in REST-Based SOA? In a forum post, Poulin asked:

If we have a UI that works with the middle- and back-end resources, do we care if … REST or Web Services are used behind the UI? If [the] UI all of a sudden becomes the orchestrator on its own (which contradicts the essence of Service with interfaces where one of [them is the] UI), how [may the] UI journey/workflow … be attributed to the communication channels - REST calls - running behind it? What constitute[s] “A REST application” … and how [does it differ] from non-REST application[s], especially from the architecture perspective? Where [is] the Architecture and where [is] the architecture Implementation?

Poulin is not alone in his confusion. The topic of REST is a minefield: it seems that most people don't understand it, even when they write authoritatively on the subject. And the true authoritative source, Dr. Roy Fielding, speaks in the precise yet obscure prose of an academic, often sowing as much confusion as he does clarity. And yet, the answers lie in Fielding's explanations, even though studying them feels a bit like sitting at the feet of the Buddha, hoping for enlightenment.

Unraveling REST
Let's begin with Wikipedia, a source Fielding bemoans as being a poor substitute for truth. Be that as it may, it's an expedient starting point. Wikipedia defines REST as "a style of software architecture for distributed hypermedia systems such as the World Wide Web." I always thought this definition was rather silly: after all, how many distributed hypermedia systems can you think of other than the Web? But in fact, this definition leads us to the answers to both of Poulin's core questions: first, what constitutes a REST application, and second, where is the architecture and where is its implementation?

Of course, Fielding's precise definition of REST differs from the Wikipedia simplification. According to Fielding, "the Representational State Transfer (REST) style is an abstraction of the architectural elements within a distributed hypermedia system." And therein lies the key to Poulin's second question: REST is an abstraction.

Of course, abstractions are nothing new-they are the basic tool of any architect, and a topic ZapThink has spoken about numerous times. But most people don't quite grok just how abstract REST is. For example, do you think that REST is HTTP-specific? No, it's not. It deals with abstracted hypertext protocols, of which HTTP is the most familiar. Does REST call for uniform interfaces consisting of GET, POST, PUT, and DELETE operations? No again. Those are examples of uniform interface operations, but REST itself doesn't specify them, other than an abstracted GET operation. And of course, resources are abstractions of server capabilities or entities, not the capabilities or entities themselves, while representations are abstractions of media type instances, not the instances themselves. Even the terms "client" and "server" are abstractions: a REST client may actually run on a physical server, and a REST server may serve as a client. In fact, there's nothing "client/server" about REST.

So when Wikipedia uses the phrase "a style of software architecture for distributed hypermedia systems such as the World Wide Web," it's pointing out that REST applies constraints to abstracted distributed hypermedia systems, of which the Web is only the most familiar example.

Confused yet? You're not alone, and that's the point. Architects look at the level of abstraction behind REST and wonder, "how can this mess be useful?" while developers look at it and think, "OK whatever, let's build a RESTful API and go from there." At that point, the architects take off their architect hats and dive into the technical details alongside the coders. The result? A lot of noise and confusion, ostensible RESTful APIs that are not really RESTful at all, and the mistaken belief that you can comply with some of the REST architectural constraints but not all of them, and still be doing some kind of REST.

And that brings us to Poulin's first question: what is a REST application anyway?

REST Applications: More than Bricks & Mortar
A REST application is a distributed hypermedia application, of course - something you apply a distributed hypermedia system to in order to accomplish some goal. Easy to say, but deceptively difficult to understand, until you realize that REST is all about distributed hypermedia applications. They're the point of REST. If you think you're "doing" REST without the goal of building a distributed hypermedia application, you're missing the point of REST entirely.

Unfortunately, most people who are trying to do REST, simply put, are missing the point of REST entirely!

It's as though we're trying to build a brick building, so we hire an architect who comes up with plans for a brick building. But we look at the plans and we don't really understand them, but we know we want to build with bricks, so we spend all our time figuring out the best way to mix mortar. Once we've come up with really good mortar, we convince ourselves we know how to build the building, even though we still don't understand the plan.

That's the state of REST today. People look at REST's four architectural constraints, and say, hmm, I don't understand the fourth one - Hypermedia as the Engine of Application State (HATEOAS). But I think I can figure out the bits about resources and representations. What they're failing to realize is the hypermedia bit is the point of what they're doing, just as actually building the building according to plan is the point of the mortar.

The mortar-first approach to REST has been institutionalized in the form of the Richardson Maturity Model, which suggests that HATEOAS is at the highest level of maturity, and it's perfectly fine to start at the lower levels and work your way up. In other words, it's fine to start construction once you have good mortar; you'll figure out the plan eventually. Clearly, that's no way to build a house!

The Right End of REST
What is it about HATEOAS that's so difficult? State engines? Computer Science 101, puhleeze. Hypermedia? Not really that confusing, either. After all, hypertext is just a document with links in it to other documents, and by generalizing hypertext to the term hypermedia, we're simply allowing for media other than HTML documents and the like. After all, a video or sound file could have a link in it, right? So, where's the confusion?

The confusion lies in the second letter A - application. As in distributed hypermedia application. The point of REST, remember? The architectural starting point for any implementation that REST constraints are appropriate for is the design of the hypermedia application that meets the given business requirements. If you look at the business requirements, and your expertise as an architect tells you that a distributed hypermedia application isn't the right thing to build, then don't use REST.

On the other hand, a distributed hypermedia application might be just the ticket. The next question you should ask is: how dynamic should this application be? In other words, what agility does the business require? Put the analysis that provides the answer to that question in your Agility Model. Then let the Agility Model - not the Richardson Maturity Model - guide your design.

RESTful Agility Levels
To illustrate the agility levels for distributed hypermedia applications that should frame your Agility Model, let's work through some concrete examples. As you go through these levels, compare them to the Richardson model.

Level 1: Static hypermedia application, consisting of a set of static Web pages containing nothing but HTML, interconnected by links. Not particularly agile. Is it REST? Yes, but in a very simplistic way. Does it meet your requirements? Probably not. (Level 1 is good enough for our ZapFlashes, however, in case you hadn't noticed.)

Level 2: Hypermedia application consisting of static Web pages that contain HTML and client-side JavaScript (no funky Ajax or the like). Pages link to each other, and the links may be dynamic, based upon client-side logic in the JavaScript.

Level 3: Hypermedia application consisting of dynamic Web pages built on the fly on the Web server, using php or Java Server Pages or whatever server scripting environment floats your boat. Pages link to each other, but the links may be dynamic, based upon server-side logic.

Level 4: Hypermedia application consisting of a set of dynamic representations that conform to a variety of media types (HTML documents, XML documents, images, video, you name it), where those representations have links to other representations, and furthermore, the links may be dynamic, based upon client-side or server-side logic or both, as appropriate.

Once you have determined the agility requirements for your application, now you may think about how best to implement its components - the hyperlinked representations. Answering that question finally leads you to a consideration of the resources that generate those representations. But you don't start with the resources, you start with the hypermedia application. You finish with the resources.

The ZapThink Take
The examples in the agility levels above are just that: examples. Particular implementation decisions that may be appropriate for a given situation. The architecture, however, is the overall, best practice-driven approach for beginning with the business challenge and working through the levels of abstraction to come up with a working implementation at the end. As an architectural style, REST is simply a set of constraints on the architecture: one way of doing things that makes it easier to solve certain problems. The architect must decide whether REST or any other style is appropriate for the problem at hand, but if you choose REST, then you must begin with the distributed hypermedia application you wish to build.

Hopefully I've answered Poulin's questions (I'm sure he'll let us know if I haven't). But there's still a part of his post left to address. If you read to the end, you'll see he wonders what happened to ZapThink. Well, Michael, we're a part of a larger company now, to be sure, but I'm still here, and I continue to do my best to push the envelope of architectural understanding. That's why we continue to update our Licensed ZapThink Architect course, which is now at version 9, and includes expanded content on REST-Based SOA, as you might expect. We hope to see you in a future class - and if you're in the Washington DC area, please come to our ZapForum networking event on October 12th and meet the "new" ZapThink. RSVP to [email protected] if you'd like to join us!

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.

IoT & Smart Cities Stories
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading...
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science" is responsible for guiding the technology strategy within Hitachi Vantara for IoT and Analytics. Bill brings a balanced business-technology approach that focuses on business outcomes to drive data, analytics and technology decisions that underpin an organization's digital transformation strategy.
DXWorldEXPO LLC, the producer of the world's most influential technology conferences and trade shows has announced the 22nd International CloudEXPO | DXWorldEXPO "Early Bird Registration" is now open. Register for Full Conference "Gold Pass" ▸ Here (Expo Hall ▸ Here)
@DevOpsSummit at Cloud Expo, taking place November 12-13 in New York City, NY, is co-located with 22nd international CloudEXPO | first international DXWorldEXPO and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time t...