"hypermedia" entries
Cross-pollinating Web communities
The integration of the Web's diverse communities broadens horizons and technology.
Web projects are integration projects, combining skills from a number of disciplines. Lousy interfaces can obscure brilliant code, and ingeniously engineered back-end systems can still fail when they hit resource limits. “Content” lurks in many guises, requiring support not only from writers and illustrators but from video specialists, game designers, and many more. Marketers have built businesses on the Web, and influence conversations from design to analytics. You don’t have to be a programmer to do great work on the Web. The Web stack is vast.
Web development models include far more than code. Creating great websites and applications demands collaboration among content creators, designers, and programmers. As applications grow larger, supporting them requires adding a cast of people who can help them scale to demand. As projects grow, specialization typically lets people focus on specific aspects of those larger disciplines, supporting networking, databases, template systems, graphics details, and much more.
In some ways, that’s a recipe for fragmentation, and some days the edges are sharp. All of these communities have different priorities, which conflict regularly. Battles over resources sharpen the axes, and memories often linger.
At the same time, though, often even in environments where resources are scarce, different perspectives can reinforce each other or create new possibilities. Sometimes, it’s just because the intersection spaces have been left fallow for a long time, but other times, the combinations themselves create new opportunities. Read more…
Implementing hypermedia clients: it’s not rocket science
Not ugly, not complicated
At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Layer 7 Principal API Architect Mike Amundsen demonstrated how to build hypermedia clients, for situations with and without humans in the driver’s seat.
(If you’d like to know more about hypermedia in general, this interview provides more background.)
In his talk, Implementing Hypermedia Clients: It’s Not Rocket Science, Mike explored how hypermedia approaches drive conversation between clients and servers, and the application structures that result from those structures.
- 1:44 – “The Semantic Gap: Hypermedia tells us what we can do, but it doesn’t say why.”
- 6:04 – Hypermedia and application control information – links!
- 8:09 – Control factors – “I accept RSS, can you give me RSS?”
- 10:41 – Foundations of the class scheduling domain example
- 16:30 – “What is a hypermedia client that a human would use?”
- 19:24 – “Faithful Hypermedia Clients (FHCs) pass along whatever the server returns, and lets a human sort it out.”
- 31:20 – “So what’s a Hypermedia for machine client?… Makes choices, not waiting for a human”
- 33:25 – Working with Maze+XML
- 37:10 – The power of generic types
If the Web Platform, JavaScript, and HTML5 interest you, consider checking out our growing collection of top-rated talks from Fluent 2013.
Looking Forward, a Leap
Will the Web shift?
Over the last few months, I keep finding new signs that the way we approach web development is about to shift. The parts – which have mostly existed for a while – haven’t completely come together yet, but the next year or two should be exciting.
In 2005, the Web changed without a major new technical push. When Jesse James Garrett wrote “Ajax: A New Approach to Web Applications“, he was describing a combination of techniques that had been around for a while but only combined in the previous few years. At about the same time, JSON, a format that Douglas Crockford had unearthed from existing JavaScript syntax, began its steep ascent. We’ve spent much of the last eight years learning the powers of these new combinations of old things, and celebrating the revitalization of the web ecosystem that they launched.
Today’s shift is a little different: change has been in the air for a while. We don’t exactly have Browser Wars any longer, though there’s still plenty of drama. HTML5 is not only in development, it’s becoming normal rapidly. Some pieces are moving and arriving faster than others, and there is always the challenge of a multi-browser world. There is much much more you can do across browsers today, though, and JavaScript has made it easier to fill the gaps.
Beyond the long-awaited features of HTML5, I see three major factors driving a larger shift:
-
The ever-increasing variety of mobile devices has shattered limits designers imposed on their work.
-
JavaScript practice is maturing, even as the first major additions to the language seem about to arrive.
-
A long slow shift toward hypermedia models (REST and beyond) for application development.
As mobile devices become ordinary, designers are having to give up the last shreds of “the web site must look like this printout”. Dynamic HTML and then Ajax gave sites much more motion and changeability, but usually within a design that was roughly stable. Creating a second stable design for mobile was never a great compromise, but the explosion of mobile devices has forced developers to move toward designs that take much heavier advantage of web-centric styling approaches. Responsive web design is evolving fast.
Exploring Hypermedia with Mike Amundsen
The Web Can Teach the Enterprise
The Web’s flexibility has helped it to survive and thrive, pushing well beyond the browser-based universe where it first showed its promise. While I’ve spent most of my time working with the HTML/CSS/JavaScript side, the HTTP side of the original HTML+HTTP combination that built the Web is perhaps even more flexible.
I enjoyed talking with Mike Amundsen, Principal API Architect at Layer 7 Technologies, who has spent much of his recent career encouraging enterprise customers to shift toward web architectures. While REST has emerged over the past decade to eclipse SOAP-based “web services”, Amundsen has eagerly promoted the next step beyond the simple CRUD-based model of early REST work: hypermedia.
Our conversation ranged from the history and foundations of REST through the many ways to integrate that work with existing enterprise practice to a glimpse at what the future might hold for frameworks, design, and architecture.
- REST as enterprise architectures principles applied to hypermedia (at 1:57)
- Transitioning from RPC-based models to hypermedia, by including additional information in response. (at 3:00)
- The value of opinionated message formats and eventual integration into opinionated frameworks. (at 5:51)
- Shifting from shared understandings of object models to messages. (at 8:50)
- “Enough coupling, but not too much” to allow mixing of technologies. (at 11:15)
- Human negotiation, HTTP negotiation, and responsive web design (at 14:20)
A Matter of Semantics
Structuring client-server communications with hypermedia messages
Messages on the Web carry three levels of information: Structure Semantics, Protocol Semantics, and Application Semantics. No matter the implementation style, all three of these are needed for any successful communication between client and server. This threesome (S-P-A) forms the essentials of communication over distributed networks.
Most of the time, though, these levels are obscured or muddled at implementation time. For example, both Protocol Semantics (how we create valid network requests) and Application Semantics (domain names like users, customers, orders, etc) are often mixed together in conversation ("You POST new users to this URL") and both of these are usually only defined in human-readable documentation and implemented in the source code of the client application itself. In other words, the protocol-level and application-level semantics are tightly coupled. An easy way to discover this is to see if you can take the same message format and implement your API using a protocol other than HTTP (e.g. WebSockets or FTP). I illustrated this "protocol-agnostic" design pattern back in 2010 ("A RESTful Hypermedia API in Three Easy Steps").
But there is a way to keep these separate from each other and view each of these aspects in their own light. In doing so, you’ll strengthen the quality and value of your message design while increasing flexibility and choices.
Structure Semantics
Structure Semantics provides the set of rules regarding how to create a well-formed message. XML has rather simple structure semantics. JSON's rules for well-formedness are a bit more vague but reachable since JSON.parse(…) turns out to be the ultimate arbiter of such things. Determining well-formedness of other, more complex media types (HTML, Atom, HAL, Collection+JSON) is tougher, but do-able even if external validators are not always available.
Building a successful web implementation that does not contain structure semantics is difficult—and that's a good thing.
ASP.NET web API rocks
Why the ASP.NET Web API Framework is an essential tool for RESTful applications.
Glenn Block (@gblock) is an O’Reilly author and senior program manager on the Windows Azure Team at Microsoft.
We sat down recently to talk about the newly released ASP.NET Web API Framework, which he helped develop, and why it will become essential to building RESTful applications.
Key points from the full video (below) interview include:
- ASP.NET Web API enables a rich set of clients to consume info [Discussed at the 1:47 mark]
- Find out if one comes out on top – MVC vs. Web API [Discussed at the 2:41 mark]
- Different clients negotiate content differently – Web API handles this with ease [Discussed at the 5:50 mark]
- Self hosting is a big deal but beyond that Web API introduces flexibility – you no longer need to use IIS [Discussed at the 9:04 mark]
- An HTTP Programming Model for Microsoft [Discussed at the 11:04 mark]
- The newest of the new – Hypermedia, OData, and Web API Contrib [Discussed at the 18:08 mark]
You can view the entire interview in the following video.