Skip navigation

This is Volume 38 of This week in REST, for June 28 2011 – August 11 2011. For more information on this blog see this post. If I missed an interesting blog post, discussion or paper – just e-mail me the links, tweet or leave a comment on the latest blog post. Thanks!

Around the Web

Building Systems with REST – (video) “Glenn Block presents how developers can build RESTful solutions using Microsoft’s technologies, especially with WCF and .NET. Glenn is a PM on the WCF team working on Microsoft’s future HTTP and REST stack. Prior to WCF he was a PM on the new MEF in .NET 4.0. He has experience both inside and outside Microsoft developing software solutions for ISVs and the enterprise. He has also been active in involving folks from the community in the development of software at Microsoft, including shipping open source products.” (by Glenn Block)

NOTIFY – “Subscribe and pull are pretty handy, but push (especially asynchronous) is just as useful, and often seems to be missing. So where is it at web level?Let’s say I have something named/identified with a URI, like myself, now everytime that’s mentioned anywhere on the web I’d like to know about it (okay not all the time, but it should at least be possible) – insert multiple scenario’s here, conclude that any notification solution needs to be as generalized as possible.So, I simply propose 3 basic things…” (by Nathan Rixham)

Resourceful != RESTful – “Resourceful routing defines paths or routes for objects that the server developer would like to have manipulated with CRUD operations.  The developer can declare an ‘invitation’ to be a resource, and the routes to index all invitations, create a new invitation, download an invitation, update or delete the invitation, are automatically created.  But, problem the first: Resourceful routing uses POST to create a new resource.  PUT is defined as creating a new resource in HTTP, and intermediaries can use that information– but only if PUT is used.  If POST is used, an intermediary can’t tell that a new resources was created. “

my WCF Web API immersion - “i had the good luck to be able to visit the Microsoft Redmond campus this past week. even better, i got the chance to spend time w/ @gblock and the WCF Web API team. and, in the process, got a serious “immersion” in the WCF Web API library. good stuff!” (by Mike Amundsen)

states: transfers and representations – “over the last several weeks, i’ve been working on a number of hypermedia designs. some of these are for clients’ production implementations but many of them are just explorations of the design patterns and constraints; ways to learn how to effectively and efficiently express a problem domain within a hypermedia type design.it’s been a very interesting experience!what follows are my notes and observations about an ongoing process of discovery related to designing and implementing hypermedia-driven solutions. ” (by Mike Amundsen)

unREST - “So, jdubray at Carnets de bord has thrown down the gauntlet, I guess. He proposes “unREST”. What is unREST? It’s, umm, not REST. Simply put, it’s RPC. Pretty bold proposition, don’t you think?Here’s to hoping that unREST sweeps the internet so that the Restafarians can focus on working out the details of trying to apply REST as given rather than cleaning up everyone’s misconception that REST is using GET over HTTP for RPC.” (by Will Hartung)

How I Became a REST “Convert” – “Much of the criticism of REST comes not from the interaction approach, but rather from the use of HTTP. Roy Fielding, the progenitor of REST, states in his dissertation that REST was initially described in the context of HTTP, but is not limited to that protocol. He states that REST is an architectural style, not an implementation, and that the Web and the use of the HTTP protocol happens to be designed under such style. I chose to implement REST using eXtensible Messaging and Presence Protocol (XMPP) as a way of doing distributed, asynchronous messaging styles of REST-based Service interaction. XMPP, also known as the Jabber Protocol, has already proven itself as a widely-used, highly-scalable messaging protocol for secure and distributed near-realtime messaging protocol. XMPP-based software is deployed widely across the Internet, and forms the basis of many high-scale messaging systems, including those used by Facebook and Google.” (by Ronald Schmelzer)

REST in the design, use, and documentation of Web APIs – (video) ““If it is on the web, HTTP is the API”“REST help us understand and take advantage of that”REST: Representational State Transfer” (by Peter Keane)

What Do URIs Mean Anyway? - “If you’ve hung around in linked data circles for any amount of time, you’ll probably have come across the httpRange-14 issue. This was an issue placed before the W3C TAG years and years ago which has become a permathread on semantic web and linked data mailing lists. The basic question (or my interpretation of it) is:Given that URIs can sometimes be used to name things that aren’t on the web (eg the novel Moby Dick) and sometimes things that are (eg the Wikipedia page about Moby Dick), how can you tell, for a given URI, how it’s being used so that you can work out what a statement (say, about its author) means?” (by Jeni Tennison)

Some People Understand REST and HTTP – “As it turns out, there are two companies that you’ve probably heard of who have APIs that are much more RESTful than many others: Twillio and GitHub. Let’s take a look at GitHub first.” (by Steve Klabnik)

JSON, data and the REST - “From its humble beginning some 10 years ago, JSON is now the light-weight data lingua franca. From the nine Web APIs I had a look at recently in the REST: From Research to Practice book, seven offered their data in JSON. These days it is possible to access and process JSON data from virtually any programming language – check out the list at json.org if you doubt that.” (by Michael Hausenblas)

Identifying Application State – new version of the W3C TAG proposed finding”As the Web has evolved from a Web of documents to a Web of applications, the use of the hash sign, #, in URIs has evolved correspondingly. Originally introduced as a static “fragment identifier” to identify locations in a document, it is now being used in many more complex ways, for example, by SVG and PDF to select from and render documents and as arguments to Web applications that are interpreted by JavaScript. Fragment identifiers are used to provide several different kinds of parameters to the client-side application, such as the actual URI of a video to be played to a video player, or the position and zoom to a map. Unlike query parameters preceded by ?, the characters in the URI bar after the # can be changed without causing the page to be reloaded. Applications and toolkits using fragment identifiers in this way often go to some effort to maintain a history and make sure the back button works as expected. Accessibility and search can, however, be compromised, because without running JavaScript, the URI has no meaning. Such uses of the “fragment identifier” have interesting and different properties, and the usage differs from the way it is described in existing specifications. Recently added functionality in [HTML5] (history.pushState() and history.replaceState()) allows browser history to be changed without causing a page reload thereby providing an alternative to the use of fragment identifiers to identify application state. This document explores the issues that arise from these new uses of fragment identifiers and attempts to define best practices. We argue that, in many cases, the use of query parameters along with the new HTML5 functionality mentioned above is preferable to fragment identifiers to identify application state.” (by T.V. Raman, Ashok Malhotra; W3C TAG)

Collection+JSON – Hypermedia Type – “Collection+JSON is a JSON-based read/write hypermedia-type designed to support management and querying of simple collections. It is similar to the The Atom Syndication Format (RFC4287) and the The Atom Publishing Protocol (RFC5023) . However, Collection+JSON defines both the format and the semantics in a single media type. It also includes support for Query Templates and expanded write support through the use of a Write Template.” (by Mike Amundsen)

Irreconcilable differences – “The ongoing battle for future control over HTML is dominated not only by the usual forces (“whose technology wins?”) but also some very polarized views of what standards are, what they should be, how standards should work and so forth. The debate over these prinicples has really slowed down the development of web standards. Many of these issues were also presented at the November 2010 W3C Technical Plenary in the “HTML Next” session.I’ve written down some of these polarized viewpoints, as an extreme position and a counterposition.” (by Larry Masinter)

Hypermedia APIs – (video) “RESTful web services are one of our core design patterns. Roy Fielding’s thesis identifies four major constraints that identify a RESTful architecture (statelessness, resource-orientation, uniform interface, hypermedia-driven application state). Many “RESTful” APIs only get 3 out of 4 of these; we’ve begun experimenting with using XHTML as a media type for our APIs (instead of the more traditional JSON or Atom types), and this provides a lot of power in terms of scalability and loose coupling between client and server. I can go over these concepts and perhaps even do some coding-on-the-fly to demonstrate some of these client and server concepts.” (by Jon Moore)

Events

IEEE Internet Computing special issue on Programmatic Interfaces for Web Applications - “Although they can take advantage of already existing Web architecture, many APIs that claim to be RESTful actually fail to do so. They overload the meaning of HTTP methods, ignore standard response codes, or do not well support hypermedia to represent relationships among application states. Moreover, developing a programmatic Web interface requires a tight integration with already existing back-end applications and infrastructures, and sometimes requires a new, highly dependable back-end technology. This special issue seeks original articles on topics related to emerging technologies and best development practices that underpin any modern programmatic Web interface. Sample topics include: best practices, patterns, and anti-patterns of a programmatic Web interface design; benchmarking and evaluation of programmatic Web interface scalability and performance in large-scale Web applications; comparisons and empirical evaluation of various styles, protocols, and descriptions for programmatic Web interfaces; reports and lessons learned from developing programmatic Web interfaces for various application domains and sectors; and end-to-end engineering of programmatic Web interfaces and their integration with existing back-end applications requiring the development of novel dependable and scalable technology frameworks.”

RESTFest is a week away - “wow, only one week before the start of RESTFest 2011! there are still some tickets to this ‘smallish’ event. at least one sponsor (Twilio) is offering ‘scholarship’ tickets to worthy individuals, too.” + more info on all the cool events happening on RESTFest 2011. (by Mike Amundsen)

Discussion groups

Comments solicited: “Providing and discovering definitions of URIs” – (W3C TAG mailing list) “As most of you know, the 9-year-old “httpRange-14″ turf war is anannoyance and embarrassment in efforts to develop RDF, linked data,the Semantic Web, and Web architecture.As a step toward getting closure I’ve prepared a document (withthe help of the TAG and the AWWSW task group):  http://www.w3.org/2001/tag/awwsw/issue57/20110625/which attempts to record the variety of approaches that have beenoffered.”

Media type derivation: standardize the + semantics? – (REST discussion group) “Due to previous posts [1] i was asking myself, if it would make sense tostandarize the usage of the + sign in media type indications.I think the benfit would be, that a more specific media type like “application/odata+atom+xml” (which is currently not existing) could be at leastinterpret as “application/atom+xml” (which is currently the media type of anodata resource [2]).”

Is there (a need for) a text/form+html media type? - (REST discussion group) “In some posts here it is mentioned, one can use simple html forms for providinga decoupled POST/PUT mechanismen. (and thus also avoiding communicatingUriTemplates)I was wondering, if a there is a specific media type for that? Ye, sure one canuse just text/html. But to support better visibility, i could imagine a mediatype text/form+html, that would better communicate the intend…Am i missing something? Is there related work?”

REST and HATEOAS in the context of native applications? - (REST discussion group) “What I really can’t wrap my head around is how, technically, have HATEOAS in anative application? I mean, when building a native application, I have tablesto display lists, buttons to do some things, etc. My understanding is that allthose should be displayed based on the data (hypermedia) received from theserver. Is that right?”

inverse of Content-Location - (REST discussion group) “To indicate which representation of a resource was sent, the server can use theContent-Location header.E.g., if a client wants an HTML version in Spanish of /news/40, the server sendsthis and addsContent-Location: /news/40.es.htmlBut how can we get to the original, unnegotiated URI from /news/40.es.html?”

Interesting tweets

@mamund – “A good #Hypermedia design does not constrain a client implementor’s ability to determine how responses are rendered. #HTTP #REST

@darrel_miller – “This http://t.co/iIorgIp makes my cry little tears of hypermedia joy.”

@WoT2011 – “#wot2011 proceedings now available in the #ACM digital library #ICPS series!http://portal.acm.org/citation.cfm?id=1993966

@mamund – “Web Intents <- i love the smell of hypermedia in morning; it smells like.. Victory! #HTTP #Hypermedia #LOD -http://j.mp/nT2bgv

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 353 other followers

%d bloggers like this: