Skip navigation

This is Volume 34 of This week in REST, for Feb 9 2011 – Mar 6 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

Long Bets: PREDICTION 601 – “The original URL for this prediction ( will no longer be available in eleven years. “Cool URIs don’t change” wrote Tim Berners-Lee in 01999, but link rot is the entropy of the web. The probability of a web document surviving in its original location decreases greatly over time. I suspect that even a relatively short time period (eleven years) is too long for a resource to survive.I would love to proven wrong.” (by Jeremy Keith)

Principles of the Same-Origin Policy – “The security model of the web platform has evolved over time to meet   the needs of new applications and to correct earlier mistakes.   Although web security has evolved largely organically, the security   model has converged towards a handful of key concepts.  This document   presents those concepts and provides advice to designers of new   pieces of the web platform.” (by Adam Barth)

Design Considerations for Protocol Extensions – “This document discusses issues related to the extensibility of Internet protocols, with a focus on the architectural design considerations involved.  Case study examples are included. It is intended to assist designers of both base protocols and extensions.” (by B. Carpenter, B. Aboba and S. Cheshire)

More on PUT Idempotency – “One of those conversations was started with a reference to a really good blog post from Alex Scordellis addressing the question of how complete representations sent in a PUT need to be. What exactly does the client need to include in the representation that they PUT – all properties? what about hyperlinks? A simple answer might be that they need to provide “everything”, but this simple answer is just not satisfactory.” (by Cornelia Davis)

Headless Foxes – “If a server is just a browser instance and the client is a browser instance then this completely changes how a web developer can think about development and debugging. What if Firebug was a server itself? You made AJAX calls to it, and it ran the “server-side” JavaScript in your browser, the same as it would on a live server. No longer would you be tied to the infrastructure of your live environment.”

my boundary issues w/ hypermedia – “as a result of my efforts to refresh my concept of hypermedia and it’s role in distributed network applications, i’ve come to view the messages passed between client and server as containing several distinct sets of information. these are: Protocol information … Domain information … State information …” (by Mike Amundsen)

i have an experiment; will you help? – “in this experiment multiple parties must build client and/or server applications to match a spec; all w/o seeing each other’s work. IOW, there is no “sample” running somewhere. in addition, the “application” uses XHTML as the base media type (sorry, no custom media type this time[grin]). finally, the only instructions for this experiment are found in a single document that contains the “semantic profile” of the target web application expressed via selected XHTML attributes (@class, @id, @name, and @rel) along with “valid values” for these attributes, descriptions of how they are used in representations, and “what these values mean.”” (by Mike Amundsen)

Principles and Patterns of Organizing Systems – New (?) course at Berkeley with slides and material being posted as the semester progresses: “The concept of an organizing system complements this categorical view with a dimensional perspective that sees these categories as sets of design patterns that reflect typical answers to questions about what is being organized, why, when, how much, who is doing the organizing, and how services are provided to interact with the organizing system. These dimensions frame trade-offs and constraints about the content, policies, and implementation of organizing systems. The primary goal of this course is to use these design dimensions to better understand traditional design patterns and their consequences, and to identify useful new ones.” (by Erik Wilde and Robert J. Glushko)

RESTful SOA in the Real World – (video) “Sastry Malladi presents different ways used by the industry to implement a RESTful SOA, detailing how eBay did it in order to achieve performance, and what lessons can be taken from that.” (by Sastry Malladi)

What is REST, Anyway? – “…so I’ve been spending some time reading more about REST, refining my thinking, and opinionizing a lot on this blog.I finally came to the conclusion that REST is not what a lot of people treat it as. It’s not a standard you can write a strict spec for, and then apply it to projects and declare “Yay!” or “Nay!” People do that, and that practice sinks a lot of projects, because it’s a silly practice.”

REST in the design, use, and documentation of Web APIs – Slide deck for intro-level REST presentation at DHapi (by Peter Keane)

This year in #rest on Freenode – Word cloud of chats from the #rest channel on Freenode. (by Kevin Burns Jr)

Calculated vs. Shipped URIs – “I wonder about the effenciencies, though. CPU is cheap and fast, bandwidth is slow and (kind of) expensive. So publishing a URI spec out-of-band and letting the client construct the actual URI with string concatenation consumes very little runtime resources. But shipping big documents loaded with hyperlinks, millions and millions of times, is going to be expensive.”

Client-driven APIs – “I lot of the REST conversations I’ve seen get tangled up because they are trying to constrain their Resource definitions too tightly, and end up restricting what the client can get at, making the client make lots of calls to get what they could get at once. Or they go the other extreme, and make Resource definition so incredibly broad that every Resource in the system meets every need that we could possibly anticipate from the client, making every response huge, bloated documents that take a long time to code, maintain, and support the bandwidth for.”

Designing RESTful Domain Application Protocols – Slide deck for presentation at JFokus: “REST is ready for the enterprise. Imagine an information platform that is open and available to systems throughout the enterprise estate. A platform that eschews integration in favour of composition, connected data over siloed databases. A networked data structure with the power to implement valuable business behaviours: a distributed, hypermedia-driven application platform. Challenging the notion that REST is suitable only for simple CRUD-based data services, in this session I show how to design and implement RESTful domain application protocols for complex business processes. With a detailed example, I show how to: – Model business processes as domain application protocols – Implement them in terms of resource lifecycles – Advertise and execute them using HTTP idioms, media types and link relation values” (by Ian Robinson)

Dog or Tail: REST or Hypermedia? – “My personal opinion is that as the tools to support hypermedia evolve, REST as we know it today is going to become a side discussion. That the principles of REST will be just small part of the discussion on how we deliver hypermedia. A few examples of why I think that are: …”

HTTP Headers – “This is a continuation of work started by Brough Davis as part of his software security project for his Masters in Information Security Engineering. The main goal of this project is to find how many sites use security relevant headers, like for example the X-XSS-Protection or X-Frame-Options headers.”

Web Apps and Web Sites – “What’s the real tradeoff in the hashbang case? The tradeoff here is between usability of two classes of clients – one that does not support Javascript and the other that supports. That’s a reasonable tradeoff! Twitter chose to not render for non-Javascript browsers. Perhaps they made that by choice by looking at the proportion of users that use non-Javascript browsers.” (by Subbu Allamaraju)

A simple overview of httpRange-14 – “Complicated issue eh? it’s certainly consumed a great deal of my time for over a year.So, here’s a simple-ish summary of the problem – disclaimer, all IMHO of course…” + The simplest view possible of httpRange-14. by the same author.

Minutes from the March 03 telcon of W3C TAG + Minutes from the 8-10 February 2011 TAG F2F Meeting


WS-REST 2011 – The list of accepted papers for WS-REST 2011 has been published. However, not all reviewers are happy with this year’s submissions. The workshop keynote will be given by Stu Charlton, you can see his sneak peek for the talk here.

ComposableWeb 2011 – “the 3rd International Workshop on Lightweight Integration on the Web (ComposableWeb 2011) will be held in conjunction with the 11th International Conference on Web Engineering (ICWE 2011) in Paphos, Cyprus, from June 20-24, 2011.”

WEWST 2011 – “The Workshop on Enhanced Web Service Technologies (WEWST), collocated with the European Conference on Web Services (ECOWS), is the premier workshop for academic and industrial communities to discuss innovative ideas and research contributions advancing the state-of-the-art in Web service technologies.” Will be held on September 14, 2011, Lugano, Switzerland.

Discussion groups

Django REST framework – Critical feedback wanted. – Discussion on new Python REST framework for Django: “Django REST framework is a lightweight REST framework for Django, that aims to make it easy to build well-connected, self-describing RESTful Web APIs.”

Cross-Origin Resource Embedding Restrictions – Discussion about an idea and specification for “…defining a way for resources to declare they are unavailable within an embedding context.”

Review of TAG issues related to “URI meaning” (long) – Overview of W3C TAG issues related to the problem of “URI meaning”.

Conversation about “Web Applications Architecture” additional background for TAG discussion

Loose coupling – a RESTful myth? – “It is often stated, that RESTful services decouples client and server, as e.g. stated here [1]:”Coupling between client and server is removed, server owners need not know about client particularities to evolve the servers without breaking clients.”But i think, the most server changes will break even the RESTfuls´ clients.”

Link header is representation metadata? – “Sorry but I need to come back to this one, can I get a definitive answer (please :)) on whether the Link header is representation metadata (like Content-Type), or not?”

Software frameworks

CRest – “CRest (Client Representational State Transfer or Client REST) is a lightweight framework aiming to simplify the integration of external REST services into java applications, somewhat in the way most of the current SOAP WSDL oriented client framework works.While SOAP is a protocol, based on a service descriptor format (WSDL) that can be used to automatically generate the client stubs, REST isn’t, and REST service implementation varies from one provider to another.CRest allows the developer to only focus on the essential aspects of the integration of a REST service.”

Interesting tweets

@kriszyp – “HTTP response of the future when you visit a site?

@AndrewWahbe – “Hash Bang URLs are a symptom, the problem is that nobody is trying to extend markup to do simple AJAXy things declaratively”

@jerenkrantz – “With due respect to @timbray & @fielding, #! in URLs indicate where REST falls down: computations – rather than documents – are exchanged.”

@fielding – “@jerenkrantz Making it easy for Web developers to create fragile, unreliable, and unsharable Web experiences is not a goal of REST.”

@mikekelly85 – “#REST is about agreeing on the best way for machines to facilitate human interaction and stay out of the way”

@dret – “finding it interesting that one of the most universal human actions (going to) has become a synonym for HTTP GET.#REST #uniforminterface

@svrc – “Trying to craft a RESTful service discovery approach with the XRD/host-meta/LRDD stuff. Finally the last nails in the UDDI coffin.”

@dret – “don’t fall prey to the dark side of where the functions lurk. focus on resources you must, and links will guide your path.#REST

@aslak_hellesoy – “WebSockets are throwing the baby out with the bathwater. Server Sent Events/EventSource and REST seems a much better stack.”

@dret – “if i can link to and reuse resources from your server, you’ve built a web app. otherwise, you’ve just built an app using browser APIs.”

@dret – “discovered that #REST can be nicely illustrated with menus, restaurants, orders, food courts, pending orders, special requests, and: food.”

@mamund – “RT @iansrobinson: @dret “… I want some term for the specialisation that helps us get things done.” <- application semantics?”

@jar346 – “”representation” is hateful not because I hate people who use it, but because its multiple definitions make you fight one another!”

@iansrobinson – “@dret Resources don’t come into it, cause I don’t think resource types are useful; resources are just sinks and sources for representations”

@iansrobinson – “@mamund Disagree that custom media types have, or ought have, PS – that’s the role of a protocol! See AtomPub (which is not a media type)”

@svrc – “@iansrobinson … because I believe custom media types are inherently the wrong long-term direction; they’re the symptom of a gap”

@mikekelly85 – “@iansrobinson media types and link relations are just another part of a uniform interface; they all provide conditions for discoverability”

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: