experimenting w/ RESTful clients
i'll be doing qutie a bit of experimenting this year. well, exploring maybe. testing my ideas.
i'll still be working quite a bit w/ REST and hypermedia. but i'll also be working on the details of describing, modeling, and implementing RESTful|hypermedia client applications. i'm particularly excited about this work.
navigating the Maze+XML
about six months ago i wrote a very simple M2M hypermedia client that can navigate a two-dimensional maze. i also created a custom media type dedicated to representing mazes. it's still a work in progress, but the basics are there. i've posted some updates on this project and i have more to do with this particular example and media type; more on that later this year.
beyond Web 2.0
i also started delivering a new talk a few months ago that covers my first examples of creating RESTful client applications. these examples are in C# (.NET on Windows), but the same principles apply to other programming environments. the main point there was to dispell the notion that "Web APIs" can't rely on hypermedia. it's my "shot" at POX-like implementations that are, IMO, polluting the Web space and frustrating the lives of Web programmers.
it's a cheery talk, really![grin]
a more ambitious endeavor
but the real work i am excited about is a bit more ambitious.
i am working on various abstract models for implementing RESTful hypermedia clients. IOW, i think there are some key abstractions that all RESTful client applications share. i am also testing some ideas on M2M (machine-to-machine) clients along the way. if this work pans out, i expect to have some clear ways to talking about designing and implementing client appliations that are hypermedia-aware, follow RESTful principles, and can support some level of M2M operations.
the basic parts
there is quite a bit i have to say on this idea, but a simple summary of the basic parts of what i currently see as "a RESTful hypermedia client model" looks like this:
- Hypermedia Type
- the heart of any RESTful client is a reliance on a hypermedia type that has built-in application controls to handle details of the transfer protocol. for example the HTML media type has applications controls for navivagating links (A), for emdebbing content (IMG), and for sending data to servers (FORM + INPUT). i've done some research into this area and am fairly confident my current abstraction of hypermedia controls is sufficient to provide a clear outline of what a hypermedia client must "know" about the representations in order to use them to drive interactions w/ servers.
- Application Level Profile Semantics
- while the media type can handle the protocol-level interactions, there are additional application semantics that need to be expressed within representations. typically this is done using @rel values (e.g. rel="edit", rel="report", etc.). but my experiments indicate that more information is tied to the app-level semantics including data values of interest (usually express using as FORM INPUT elements in HTML). i am looking to "document" these app-level semantics as a "profile" that is downloadable and parse-able. much of this thinking is influenced by the XMDP project.
- Client-Side Application State
- something else that is needed to make true M2M hypermedia work is a way to express and manage client-side state. just as my work w/ custom media types has been viewed by some as contrary to RESTful principles, i suspect my efforts this year to abstract client-side state into a usable form will rub some folks the wrong way. i've not yet found much on this topic, but currently i am experimenting w/ establishing a "standard" way to store and recall client state and use it to populate "forms", URI templates, and other request elements in the HTTP protocol.
- M2M DSL
- more than a year ago, Guilherme Silveira showed me the power of a hypermedia DSL in his RESTfulie project. since then, i have been thinking about the possibilities of using a general DSL for "driving" hypermedia clients directly (i.e. machine-to-machine). to my way of thinking, if the media type has well-defined hypermedia application controls, and the application-level semantics are properly expressed through a "profile", and the client-state management is sufficently abstracted to allow interaction between the representations & client-state, AND there is a dedicated hypermedia-ware DSL available to drive that interaction, much can be accomplished. i have in mind a very simple Turing complete DSL that handles basic branching and memory manipulation.
prototyping|enjoying it all
currently i am working on prototyping these ideas using a common Web browser driven via javascript. these first examples rely on a single HTML page to "host" the javascript "client." (borrowing from the Single Page Interface idea) this client has modules for parsing the hypermedia representations, consuming and parsing the application profile, and managing the client-side state. my M2M DSL is just a kernel of an idea, but hopefully will be coming along soon, too.
while i know how i'd like all this work to turn out, i must admit i am not exactly sure where it's going. and that's part of the fun of it for me. see, i'm truely experimenting here; testing my ideas and seeing where they lead.