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”.”
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.”
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.”