Home
as i prepare for my
Hypermedia Workshop
for REST Fest 2010 this september, i am reviewing lots
of material regarding hyper
[media |
text |
data | etc.].
along the way, i pulled up the always entertaining
slide deck
from Roy T. Fielding's talk at
ApacheCon Europe - 2008.
the deck itself is notable for it's clarity and simplicity. i still enjoy reviewing it years after i first saw it.
SPOILER ALERT: i love the "Relaxation" section (e.g. "Clearly it's time to start messing with minds.")
hypermedia is...
his summary of Hyper[text|media] is a case in point. i've included a re-working of this part of this presentation (see slide 50) as an example of his clean and direct approach. BTW - the next three items are lifted directly from his slides w/o editing.
- non-linear documents
-
"By 'hypertext,' I mean non-sequential writing - text that branches and allows choices to the reader, best read at an interactive screen. As popularly conceived, this is a series of text chunks connected by links which offer the reader different pathways"
- selectable GUI controls
-
"Hypertext is a computer-supported medium for information in which many interlinked documents are displayed with their links on a high-resolution computer screen."
- data-guided controls
-
"The simultaneous presentation of information and controls such that the information becomes the affordance through which the user obtains choices and selects actions. Hypertext does not need to be HTML on a browser; machines can follow links when they understand the data format and relationship types"
data as first-class elements
note that Fielding's description of hyper[media|text|data] is more than just linking text (non-linear documents) or enhancing the user interface (selectable GUI controls) and is not limited to a particular data format (HTML). for Fielding, "simultaneous presentation of information and controls" means the message is more than raw data - it also contains application controls. in addition, Fielding asserts these controls are "the affordance through which the user obtains choices." IOW, the details on how users can change the current state of the application is contained within the message itself (not in the application code running in the client).
this view of hypermedia elevates the role the message itself plays in the design & implementation of distributed network applications and is a key aspect of the REST architectural style defined in Fielding's dissertation. the importance of this aspect of Fielding's work has been acknowledged in the book Software Architecture: Foundations, Theory, and Practice (2010):
"REST not only gives data elements first-class status, they surpass in importance both processing and connecting elements."
(Taylor, Medvidovic, & Dashofy)
in my current work, this understanding that data itself can be a first-class element in software architecture has lead to my study of Hypermedia Types; their nature, role, and influence on the design and implementation of distributed network applications. the results of that study can be applied directly to the process of actively designing and documenting (hyper)media-types when implementing WWW applications.
and that's what my Hypermedia Workshop is all about.
a new way to think about old things
the general idea of hypermedia has been around for a long time. in 2000, Roy T. Fielding's dissertation noted (emphasis mine):
[The] REST [style] is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
although Fielding's work details just one example of using hypermedia (that of driving the state of applications in a distributed network), since so much of what he wrote about relates directly to the way the Web works today, quite a few folks actively discuss this (and other points) on a regular basis.
however, over the last year or so, my focus been on the way hypermedia documents express a defined set of factors that are common throughout the Web, no matter the media-type or client applications being used. i think we greatly improve the quality of content on the Internet when these basic hypermedia factors appear in all types of responses, not just Web pages loaded into browsers to be read by humans.
we can do better
i am also, frankly, annoyed by the recent proliferation of "Web APIs" that emit responses that are devoid of all but the most mundane of the hypermedia factors (e.g. read-only outbound links); APIs that often require consumers to write a new client application for each set of data. especially when doing it better is not so difficult. i think Web developers are missing huge opportunities to produce high-quality information easily available to a wide range of clients. i am also concerned that recent trends that emphasize the data itself at the expense of these important factors is leading us all to a lower-quality user (and developer) experience on the Web.
so this workshop is my way to encourage the use of hypermedia in all aspects of the Web.
not just the head, but also the hands
this workshop will also be a chance for me to get back to doing something i really love: hands-on training. although this is an all-day event, i won't be lecturing all the time. instead, the workshop will be a mix of presentation, discussion, and hands-on coding. my slides are meant to introduce ideas and provoke thought & discussion. the hands-on work allows everyone to experiment with these same ideas and talk about the results. the aim is to engage not just the head, but also the hands.
the workshop
the complete details of the event are available at the REST Fest workshop page, but here are some highlights:
In this one-day workshop, attendees will learn how to implement an alternative to one-off Web APIs using Hypermedia Engines. Topics covered include:
- Hypermedia Past and Present
- Nine Essential Hypermedia Factors
- Selecting the Proper Data Format
- Adding Hypermedia Application Controls to your Responses
- Binding Protocol Methods to your Hypermedia Controls
- Serving Up your Hypermedia
- Writing Clients that Understand your Hypermedia
- Documenting your Hypermedia
- and more...
i'm excited about this workshop because it gives me a chance to share my experience and ideas with others and because if offers the opportunity to engage in a dialog on what i think is a very important subject.
i'll be there. will you join me?
i'll be attending REST Fest 2010 this September 17th & 18th.
in fact, i'm a
co-chair of the event w/ my good friend
Benjamin Young.
there are lots of conferences, seminars, workshops, etc. but unlike many existing events i've attended,
REST Fest follows the
Open Spaces
"unconference" model and is designed to focus on practical issues, emphasizes discussion over lectures, and
encourages hacking on code as a social activity.
we're hoping this approach is interesting enough to attract a relatively small, but animated group of like-minded REST-o-philes to the NEXT Innovation Center in Greenville, SC for two days of high-quality, low-stress interaction with some cool folks.
to that end, here's some basic principles we kept in mind as we put together the event:
less theory, more practice
theories, studies, and formal papers on network architecture and the future of the web, yada-yada are cool, but that's not what we're interested in here. instead, if you're "doing it", we wanna see it.
if you're building a RESTful HTTP library, we'd like to hear about it. if you're using and existing HTTP library in a RESTful way, show it off! if you've got some hard-won experience wrangling some existing framework into a RESTful result, we'd like to see it in action.
we all talk
another thing we decided early on is to make the entire event as interactive as possible. that means we are encouraging all attendees to come not just listen but also to talk. while we will have a few "Selected Talks" that feature smart folks saying smart stuff, we are also setting aside a large block of time for "Lightning Talks" or Five Slides in Five Minutes. in fact, we hope everyone will offer at least one FiveInFive talk this year.
so we made it super easy to propose a talk. when you register for REST Fest, all you need to do is supply a title, short abstract, and audience level (Beginner, Intermediate, Advanced) for one or more talks and that's it. All proposed talks will get at least a FiveInFive slot for the Saturday sessions. Some talks may also be picked as a "Selected Talk" (30+ mins).
and your talk proposals don't have to be all "Here's the right way to do X" or "Now I'll give you the big secret..." instead, maybe you want to talk about how hard it is to understand some part of the REST arch style or how much of a pain it is to do something "simple" over HTTP, etc. So you might want to offer a "How Do I do X?" talk or "Why is REST so danged Y?" talk and see what kind of feedback you get.
cuz, the point is - we all need a chance to speak out minds, right?
we all listen
since everyone will be talking, that means we all get to listen, too. and we mean active listening; as in questions, comments, suggestions, elaborations, etc. we'll be setting aside Breakout Rooms where people can gather to explore topics brought up in the FiveInFive sessions. So attendees can create their own breakout sessions on stuff the attendees think is interesting.
this is especially true for FiveInFive talks that pose a question instead of trying to solve a problem. maybe a bunch of folks all have the same question! maybe they all have a tiny piece of the answer. if we all listen, we might just be able to put it all together.
hacking is a good thing
we also wanted to make it easy to go off and hack away at some exsiting library or framework project; even make it possible for folks to come as a group and spend their time building cool stuff. so we'll have a Hack Room open throughout the event.
got a project you want to share with others? get some feedback on? looking to rope a few code-jockeys into helping you build a cool framework? this is the place to give it a shot. who knows, maybe someone will get some ideas from the talks and head into the Hack Room to build "the ultimate HTTP library" all at the same time!
hey, it could happen.
oh yeah, i should be cheap, too.
i've attended enough events that cost upwards of four figures; sheesh! we wanted to make it easy for everyone to attend without breaking the bank. if we could, we'd make it all free (but we can't - yet). this year, you can attend REST Fest for as little as 25 USD; 50 USD if you also join in the pre-conference workshop.
that way, you don't have to worry about justifying a huge conference fee to your boss or raiding the family vaction money just to get a chance to interact w/ some like-minded folks.
so that's basically it
we wanted to hang out w/ with smart folks, talk about real-life examples of REST and HTTP programming, get a chance to say our piece, maybe do a little hacking, and not go broke in the process.
so what do you say? will you join us?
employing hypermedia types on the WWW has a number of advantages. below is a set
of seven key aspects of hypermedia designs that are worth noting. i've used this
list a number of times when talking to folks about the power of
hypermedia
designs when compared to the more common
Web 2.0,
SOAP
RPC over HTTP,
Discovery-Based,
and other approaches to exposing functional data on the Web.
"The WWW is fundamentally a distributed hypermedia application."
- Address Abstraction
-
Hypermedia types use designated elements (e.g.
A,FORM,IMG, etc.) and link relations (@rel) as 'tokens' for clients to watch for. The actual contents of the associated URI is not important to the client. This means the URIs can safely change over time. - Protocol Abstraction
- Hypermedia types can be designed as protocol agnostic. Links can use any protocol supported by the [client|server] and can safely change over time as needed.
- Object Model Abstraction
- Hypermedia types can expose state representation transfers that need not match to any server-side object model or storage model. Passing representations means the server can safely change it's internal object/storage details without breaking the client.
- Workflow Abstraction
- Hypermedia programming allows sharing representations and links as a means to drive applications. That means servers can, over time, safely change the flow of an application by introducing new links and/or new state transfers or by changing the order of the existing state transfers.
- Function Call Abstraction
- Using state transfers means data passed between clients and servers can be in different formats, based on the use case requirements. That includes typical name/value pairs (name=mike&size=large...), binary objects (e.g. image transfers passed via base64 encoding), or even direct transmission of data blocks (e.g. XML, JSON, etc.)
- Asynchronous Evolvability
- Using Hypermedia types means authors can add new features to the messages without breaking existing clients. The media-type itself can be safely "versioned" in ways that will not break deployed clients, too. This also means that new clients can take advantage of the new features while co-existing with the old clients.
- Client-Driven Composability
- Clients that understand a sufficient range of media types can "compose" their own work by leveraging multiple servers, negotiating media types with those servers and, in effect, creating an individualized "program" for the client to follow. Hypermedia types encourage this "composability" since servers can offer up data via well-known hypermedia types and allow clients to determine what tasks are done at which servers using the hypermedia application control information provided in responses.
