ENTRIES TAGGED "hypermedia"
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.
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.
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.
The Web Can Teach the Enterprise
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)
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 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.
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.