Skip navigation

This is Volume 35 of This week in REST, for Mar 7 2011 – Mar 26 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

Is it RESTful? – “This site helps people to figure out if their Web site and APIs are RESTful, by interactively interrogating them and applying a suite of cloud-based analytics. Or, it gives a completely random answer.”

Nobody uses the term “web services” anymore. – “Apropos revising RESTful Web Services, I have a question for you. When I started talking with people as part of my job search, I noticed that nobody uses the term “web services” anymore. Everyone talks about “APIs”.”

Trends in Web Applications and the Implications on Standardization – “Advancements in the design of web browsers have introduced   fundamental changes to the architecture of application protocols.   The widespread availability and growing sophistication of JavaScript   interpreters in browsers enables web servers to push to browsers all   of the application logic required to implement a client-server   protocol.  Consequently, many client-server applications that once   required an installed client on a host computer now can rely simply   on a modern browser to act as a client for the purposes of a   particular application.”

IETF technical plenary: the end of application protocols – “As described, the session suggests a failure to recognize at least two architectural issues. One is that it mandates full-time connectivity.  The other is that protocolsthat it says are no longer needed are in fact still needed in some form, albeitas a layer above HTTP, rather than TCP.”

AJAX is the new NAT – “What we need to do is acknowledge that AJAX has happened. The Web hasn’t been “hypertext” for a long time now.”

BPM with REST – “Cesare Pautasso discusses the conceptual relationship between business processes and stateful RESTful services, showing how BPM can be used to design and implement hypermedia-based services.”

Give me a REST, I just want to get my Message across – “When you start building applications on top of WebSockets (and degrading) you also start to think about different architectures. WebSockets gives us a rich, fast, bi-directional pipe between the client and server. Whether you are a Socket.IO lover with Node++, or an Enterprise sort on Kaazing, you can start to deal with a very simple messaging API (that degrades).”

Resource Identification and Query Parameters in URIs – “An interesting topic came up at QCon London: What identifies a resource? One view is that resources in REST are identified without considering the query parameters in the URI. In most RESTafarians’ view, none of the characters in the URI should have special meaning. But even if one happens to agree with this, it’s still interesting to find out what the specs actually say.”

Microsoft gets serious about Http – Presentation by Darrel Miller.

state transitions: simple and complex – “it’s easy to get bogged down in what state transitions “are”, how they “work”, and their role in hypermedia and the Web in general. i’m going to skip over all that here[grin]. instead, i want to focus on some of the concrete details of state transitions for hypermedia and why i think identifying them is critical for building robust distributed applications.”

Repurposing the Hash Sign for the New Web – “The Hash sign (#) in a URI was originally used to introduce a static “fragment identifier”, but recently it is being used in many more complex ways as it is set by and interpreted by JavaScript in Web applications. 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 search 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 differs from the way it is currently described in specs. This document explores the issues that arise from these new uses of fragment identifiers, and attempts to define best practices.”

Documents in applications – “It has become fashionable to divide Web resources into two broad categories: each resource is either a document, rendered primarily in HTML, or an AJAX-style  Web application that uses Javascript to facilitate very dynamic interaction, navigation and information retrieval.  My purpose here is to argue that we need to be more careful, that many AJAX applications in fact provide access to documents after all, and that the Web would be much more robust if we took some care to identify and access those documents using the same sorts of URIs that we use for other Web documents.”

Managing Relationships between Resources with URIs – “The big benefit of systems based on addressible resources is that the resources are identified by portable URIs. The big payoff is that, unlike database primary keys, the identifiers are usable in a much broader context than just that system itself. In most cases, those URIs are, in fact, URLs. But since they are addressable, we’re not limited by things like PK values or names that only our system understands. We can share those identifiers between disparate systems.”

REST, Hypermedia, and Query Strings – “Now, I agree totally that the path part of the URI — that is, everything in front of the first “?” or “#” should be treated as an immutable, opaque string. That’s just saying that the server controls that part, and can change it at a moment’s notice. The client must be decoupled from the path of the URI. But the query string part of the URI is not so clear.”

Hash URIs – “Having looked at the advantages and disadvantages, I would echo what seems to be the general sentiment around traditional server-based websites that use hash-bang URIs: pages that give different content should have different base URIs, not just different fragment identifiers. In particular, if you’re serving large amounts of document-oriented content through hash-bang URIs, consider swapping things around and having hashless URIs for the content that then transclude in the large headers, footers and side bars that form the static part of your site.”


WS-REST 2011 – Preliminary proceedings for the WS-REST workshop have been published online.

Leave a Reply

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

You are commenting using your 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

%d bloggers like this: