This Week in #REST – Volume 46 (Sep 22 2012 – Nov 25 2012)

This is Volume 45 of This week in REST, for September 22 2012 – November 25 2012. 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

hm-json Browser – “hm-json Browser is a JavaScript client that can browse and interact with hm-json (Hypermedia JSON) APIs. It is intended to: 1. Show that JSON can be hypermedia, and 2. Make discovering and using an API as easy as surfing the Web.” (by David Gauer)

From Webhooks to the Evented Web – “These days, the people that really get it are starting to build some really neat things. Webhooks have spread enough that you can at least reference them or the idea of HTTP callbacks and not have to explain yourself. Now is maybe the perfect time for me to put a few specific projects into motion that could at least provide a tangible foundation for building out the Evented Web. Not just vague notions. The most immediate thing is a lightweight spec for implementing webhooks.” (by Jeff Lindsay)

Introducing Client-Server Domain Separation – “I have been thinking about Client-Server Domain Separation CSDS for a while. And I think it is time to do a brain dump. So here is the definition CSDS – if you don’t want to read the whole post. CSDS defines a single constraint which is just an expansion on REST’s client-server constraint: Client and server must define and live in their own bounded context. This will lead to 1) cleaner separation of concerns among clients and servers and 2) adoption of API as the building blocks of complex systems in an SOA world. CSDS is also not compatible with HATEOAS – as we will see. If you need to find out how such a seemingly trivial constraint can have such an impact, read the rest.” (by Ali Kheyrollahi)

REST’s “Inverted” Architecture Model – “HTTP was designed to favor runtime stability in the long term (measured in years/decades) over ease of implementation. To do this, it relies on some very simple –but powerful – constraints. … Implementing large-scale solutions under the above constraints is usually quite different from what developers learn in school. Most training recommends the reverse of the above rules.” (by Mike Amundsen)

When REST isn’t good enough – “Instead of a public REST API, we provide client libraries in seven languages to ease integration with our gateway. This covers almost every modern web application language. Using our Java library, we can also reach other JVM languages like Clojure and Scala. As you can imagine, these libraries are built on top of a REST API. Occasionally we are asked why we don’t document and expose the REST API, and this inevitably sparks a discussion on our team about the tradeoffs. During these discussions there are three topics that often come up: Security, Platform Support, and Backwards Compatibility. These three topics have kept us in favor of providing client libraries instead of direct access to the low level API.” (by John Downey)

Designing Hypermedia APIs – (video recording of presentation from Øredev) “Ruby on Rails did a lot to bring REST to developers, but its conception leaves the REST devotee feeling a bit empty. “Where’s the hypermedia?” she says. “REST isn’t RPC,” he may cry. In this talk, Steve will explain how to design your APIs so that they truly embrace the web and HTTP. Pros and cons of this approach will be discussed, as well as why many aren’t building things this way yet.” (by Steve Klabnik)

Hypermedia with XHTML – “Back in 2008 at a developer meeting, we discussed the future client side of the Seam framework project. One of major items were rich clients, and how we could go beyond server-rendered JSF pages. The first step was to make creation of HTTP remote interfaces easier, so we integrated with a JAX-RS implementation. There was still an open TODO item, the actual representation of state in hypermedia. Sure, you could easily transform JPA entity data to and from JSON or your own XML dialect, but you wouldn’t really get HATEOAS for free. We thought about using XHTML for hypermedia, as it was already the primary template format for JSF. Since then I’ve worked on other things, but always had this problem as “unsolved” in my mind.” (by Christian Bauer)

Serendipitous Integration With Templated Webhooks – “A templated webhook is exactly what the name implies: a webhook that’s produced from a template. The idea is that your system emits events as JSON that are then applied to user-defined templates to construct the final request. A webhook template can describe each part of the webhook request: Target URL, HTTP Headers, Body. The target URL is a URI Template, and the headers and body are mustache templates. A JSON object can then be passed in which is applied to each part, producing the final request.” (by Mike Kelly)

Combining HTML Hypermedia APIs and Adaptive Web Design – “Thoughts, issues and ideas on combining HTML Hypermedia APIs and Adaptive Web Design. Possibly, in the future, also code examples.”

Composition of RESTful Services – presentation slides about RESTful service composition (by Cesare Pautasso)

OPTIONS is not the method you’re looking for – “Once in a while, people ask me whether they should use the OPTIONS HTTP method, and whether we should try to define formats for discovering resource capabilities with it. I usually say “no.” This is a personal position, nothing “official”. That said, the conversation usually goes like this:” (by Mark Nottingham)

Hypermedia and ASP.NET Web API – presentation slides from a talk at Oredev. Video recording is here. (by Glenn Block)

RESTful API Architecture – Video of an overview of RESTful API architecture. (by Blake Dournaee)

The Costs and Benefits of Building Hypermedia APIs (with Node.js) – (video) Mike Amundsen explores a way of designing hypermedia APIs based on messages instead of URIs, plus documenting, extending, versioning and registering hypermedia designs. (by Mike Amundsen)

What HTTP/2.0 Will Do For You – “An overview of where HTTP/2.0 is at and what it might mean for how we deploy and operate the Web, from the chair of the IETF HTTPbis Working Group.” (by Mark Nottingham)

API Academy – “series of short (5 min) informative videos on topics related to the Web, APIs, and solution design/implementation.” (by Mike Amundsen and Ronnie Mitra)

The Web engineer’s online toolbox – “I wanted to compile a list of online, Web-based tools that Web engineers can use for their work in development, testing, debugging and documentation. The requirements for a tool to make the list are: must be a live Web application (no extensions or apps you have to host yourself), free to use (some kind of free plan available), generic applicability (not usable only for a specific application/platform), and must be useful to Web engineers (not just for Web site design).” (disclaimer: I am the author of this post) (by Ivan Zuzak)

“Such a rich set of affordances” – A Hypermedia Tale – video of a talk given at the Defrag Conference 2012 (by Mike Amundsen)

I got 99 problems, but ReST ain’t one – (slides) “Review of Web, Query, and HATEOAS designs many call ReST. Motivations behind choices.” (by Adrian Cole)

The HTTP OPTIONS method and potential for self-describing RESTful APIs – “The OPTIONS method is a somewhat obscure part of the HTTP standard that could be used today with a strong impact on the interconnectedness of the interwebs while requiring minimal effort. It’s role is well defined in RFC2616, yet no web services that I can find are taking advantage of it.” (by Zac Stewart)

Caching POST– “So, POST caching is possible, but it’s only useful in a very narrow way — when you want to use the result of the POST to serve future GETs for the same URI. And, as the spec says, it’s not commonly implemented. See Subbu’s example and links to discussion at the time for more information.” (by MArk Nottingham)

The Hypermedia Debate – “We liked JSON but realized there was no standard for how to represent hypermedia. XML has Atom links, which most people seem to favor, but JSON was still in flux. The two main contenders at the time appeared to be Collection+JSON and HAL. We almost decided to ditch a vendor specific media types in favor of these, but were confused how the client would know what they were getting back, other than a data payload stuffed inside a known hypermedia-ready envelope.” (by Luke Stokes)

My Pain With a Non Hypermedia HTTP API– “What matters for this post is that our current API design follows a similar approach to the ones known from Facebook, Twitter or GitHub, which is basically Remote Procedure Call (RPC) over HTTP with extensive out of band documentation. That’s what all the large API providers seem to do. .. And that’s where I think hypermedia can help. It seems to change the game plan between an API provider and its consumers in a way that naturally enforces loose coupling.” (by Björn Rochel)

Versioning RESTful Services – “First, note that while the focus here is on RESTful services and not just HTTP services, the same principles can potentially apply to HTTP services that are not fully RESTful (for example, HTTP services that do not use hypermedia as a state transition mechanism). When talking about versioning, the most important question to ask is “what are you wanting to version?” The logical extension to this question is, “what is the contract between your service and client?” This is naturally important since the contract is the thing you want to version.” (by Howard Dierking)

Events and publications

13th International Conference on Web Information Systems Engineering – The WISE 2012 conference was held in Paphos, Cyprus, on November 28-30, 2012. The program from the conference is here and the proceedings here.

The ACM Hypertext and Social Media conference – The 2012 Hypertext conference will be held in Paris, France from May 1 to May 3 2013. You can view the CFP here.

Interesting tweets

@progrium – “I’m sad that a lot of the extensibility designed into HTTP is rendered useless by proxies.”

@pautasso – “”Roy Fielding looked at the Web and saw it was good.” Jason Bloomberg #techsym2012#rest http://yfrog.com/o03rxbp”

@dret – “reading #REST discussion threads, and the worst possible insult seems to be: “THIS IS COUPLING!” from now on we should all say “the c-thing””

@pkeane – “re: HATEAOS, JSON lack of forms much more problematic than lack of links”

@dret – “#REST requires us to design media types as a mix of data models and interaction models. how we do that is up to us, but we have to do it.”

@progrium – “Node.js community reinvents control flows and IO streams. Reminds me how SOAP community reinvented HTTP verbs in WS-Transfer.”

@pkeane – “baffled by talk of “restful endpoints”. Huh? And zero mention/understanding of hypermedia :(. #javascript #mvc”

@pkeane – “I’m pretty sure that you could build v. cool hypermedia-driven rich javascript UI’s w/ careful design of json+<…> media type”

@dret – “if your #REST services make assumptions about the metamodel or model on client or server beyond the service surface: that’s bad model creep.”

@dret – “somebody talking of “RESTful startpoints” probably gets #REST, somebody talking of “RESTful endpoints” probably doesn’t.”

This Week in #REST – Volume 45 (Aug 25 2012 – Sep 21 2012)

This is Volume 45 of This week in REST, for August 25 2012 – September 21 2012. 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

Every discussion about REST ever – funny video that Jon Moore put together.

Why PATCH is good for your HTTP API? – “A common problem for APIs is partial update; when the client wants to change just one part of a resource’s state.  … A better way is to use the HTTP PATCH method. Rather than putting the semantics into the URI, or into an application-specific POST, we put them into a generic* request format — you can think of this as a diff — which is activated by the PATCH method.” (by Mark Nottingham)

Hypermedia Programming: Lists – “The most straightforward list representation actually doesn’t look that different than a handwritten to-do list; the text/uri-list media type just consists of one URI per line. This makes the format incredibly concise, since there is very little syntactic structure (just interleaved line breaks!), while making it completely general through the use of globally unambiguous identifiers. Now let’s talk about manipulating this list with HTTP.” (by Jon Moore)

REST – Epic Semantic Fail – “Roy Fielding writes a PhD dissertation describing the architectural style of the World Wide Web. He coins the term ‘Representational State Transfer’ (REST) to describe it – after all, if you’re going to talk about something, you need to give it a name. Somehow, in a semantic shift of epic fail proportions, the term REST has also come to mean something completely different to most people, a ‘style’ of writing web services. This style has no agreed protocol.” (by Mike Hadlow)

RESTful or not? Here comes trouble! – “Very often (very often) I am asked to tell someone if their implementation is “RESTful”, “is a REST API”, is “RESTful enough”, etc. Rarely am I asked to tell someone if their chosen architectural style is appropriate for the problem at hand. IOW, people want to know if the work fits a label invented over a decade ago by a PhD candidate in his dissertation. Almost everytime the answer is the same: “NO.” This answer makes some people sad. Some angry. Occasionally, some people ask questions about why I gave the answer I did. Rarely, do people ask me if the implementation is appropriate for the intended use.” (by Mike Amundsen)

Resources and Query Parameters – “What kind of string is this? http://example.com/path?query=foo I often run into folks that think this string identifies a “http://example.com/path&#8221; resource that happens to take a parameter, which is understandable, because this is how almost every web framework is set up to implement it (identify your “/path” route, set up your controller, pick off the parameters as arguments). However, from an HTTP point of view, and especially from a hypermedia point of view, this isn’t right.” (by Jon Moore)

Discussion groups

REST and DELETE – “There’s something I’m not getting about REST. We’re supposed to use HTTP verbs like GET, PUT, POST and DELETE. But we’re also supposed to be avoiding server state, like sessions. How can we have a stateless protocol (that is, a protocol in which all state is saved in the client, using the REST hierarchy as a sort of state machine), that supports a DELETE operation? Are some HTTP verbs more RESTful than others? It seems like PUT, POST and DELETE are all about storing state on the server.”

Bookmark stability – “one of the obligations a server has in a RESTful system (IMHO anyway) is to keep those URIs stable that make good bookmarks. (as in “Cool URIs don’t change”). Some questions keep bugging me: – Should all URIs a server makes known to clients be considered possible bookmarks? If not, how do I differentiate between those that are and those that are not?”

Events and publications

RESTFest 2012 – The annual RESTFest unconference was again a success. Check out the video on Vimeo here.

SOA patterns– “There’s a lot of material and guidance on the Service Orientation (SO of SOA) and the business aspects of SOA, There are even few books on low-level design patterns for SOA but the Architecture (the A of SOA) is regrettably somewhat neglected. The SOA patterns book aims to fill this gap and includes 26 patterns and 4 anti-patterns that are useful for building and designing real-world SOAs.”

IEEE Internet Computing special issue on Programmatic Interfaces for Web Applications – This special issue of the IEEE IC magazine includes several interesting papers, including one by Silvia Schreier and myself titled “ArRESTed Development: Guidelines for Designing REST Frameworks”. Here is the abstract of the special issue: “Programmatic interfaces for Web applications have created new opportunities for vendors to build developer ecosystems. Such interfaces have also become a core feature that developers expect from any Web application. In this special issue, the guest editors collect a number of contributions that address some of the challenges of designing modern Web service APIs, take a close look at the underlying technologies, and provide examples of the real-world impact of programmatic Web interfaces.” 

Web Services and Formal Methods – The 9th International Workshop on Web Services and Formal Methods, WS-FM 2012 was held on September 6-7, 2012 in Tallinn, Estonia. Check out the pre-proceedings for the papers that were presented.

Interesting tweets

@beandog76 – “I’m going to invent new HTTP status codes: 508 NOT MY FAULT and 208 WORKS FOR ME”

@dret – “link relation tells you *why* you might want to follow a link; a media type tells you *what* you find there when following it. #REST”

This Week in #REST – Volume 44 (Apr 4 2012 – Aug 24 2012)

This is Volume 44 of This week in REST, for April 4 2012 – August 24 2012. 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

HTTPSTER T-shirt – You know you want it.

IANA and the Last Layer of REST’s “Uniform Interface” – “I confess I have never fully understood how exactly REST manages to shift the coordination model away from centralised orchestration (à la WS-BPEL) to one of decentralised choreography (which is what the HatEoAS principle is all about). … I learnt that IANA has published a standard list of link relations that servers can use to describe the “next steps” that a client can perform, and since these are by definition “well-understood” descriptions, clients do not need prior negotiation with the server to learn what they mean!” (by Ganesh Prasad)

API Design – “API design is very much like user interface and user experience design. Your target audience has different needs and characteristics, but they’re still humans who are looking to get a job done. As with a friendly, usable app UI, you’re still trying to make your API: Intuitive, Forgiving, Frictionless” (by Matt Gemmell)

The State of pushState and REST – “If your “session” state is living in the client, you can be tempted to use the state object in pushState to store some information related to the view change. We have done this in the breadcrumb solution as we need to know if you are going forward or backwards in the stack. This is harder than you think, and our solution ended up being holding an index to where the client was in the stack. But wait, this means that if the user copies the given URL and opens it in a new session (new browser window say) then you may be in a different state. The RESTafarians do not rejoice, including Jeremy Ashkenas:” (by Dion Almaer)

if #REST was … #iLikeThisGame – A game of “if REST was…”, including: “if #REST was an object transfer method…”, “if #REST was a file transfer method…” and “if #REST was a way to transfer representations of transient state…”. (by Mike Amundsen)

Wrestling With The Immaturity of Level 3 REST – “The biggest challenge we faced overall was the lack of maturity in Level 3 REST. The key aspect of Level 3 REST that we solved in our API was managing the links between resources. This key aspect of REST is really important because it gives the client developer a way to write apps that know the names of related data and actions without having to know the addresses of these links or how to build them. It’s like moving from Assembly language to C; in Assembler one cares a lot about how memory addresses are structured. In C, you don’t care so much about addresses, you care about the names of things instead. The compiler takes care of the addresses for you.” (by Matthew Bishop)

Using HTML as the Media Type for your API– “I’ve heard many folks say that HTML is primarily for presentation and not for conveying information, and hence it isn’t suitable for API use. Hogwash, I say! There are many web experts (like Kimberly Blessing) who would insist that markup is exactly for conveying semantics and that presentation should be a CSS concern. People seem to forget that web sites actually worked before CSS or Javascript was invented! I rely on this heavily for my HTML APIs.” (by Jon Moore)

Your API is not RESTful – “Two such leading standards for API design used to be XML-RPC and SOAP but nowadays RESTful APIs is all the hype. It is clean, powerful and easily maintainable. But also completely misunderstood.This is my gripe with “RESTful APIs” — companies are boasting openly about their shiny new API and how RESTful it is. And then it turns out they have implemented RPC over HTTP. Maybe they even throw in a link to the Wikipedia article. But somehow they fail to grasp the guiding principles in that article.The very essence of REST is about four distinct criteria.” (by Tobias Sjösten)

Best Practice For The Use of PATCH in RESTful API Design – “The bigger problem I see is that we as API designers don’t really know how to use PATCH. There is no guidance around its use other than to “use it for partial updates”. Everyone agrees that we need more fine-grained control over updating resources, but this level of granularity needs detailed specification. We simply don’t have that anywhere. Well, we’ve got it now, and remember that you read it here first :-).” (by Ganesh Prasad)

Combining HTML Hypermedia APIs and Adaptive Web Design – “HTML is the lowest common denominator in a world were the number of devices are steadily growing. In such a world, our API should be hypermedia driven and we should consider choosing HTML as the media type for our APIs. If we choose this, we can enhance the API with CSS and JavaScript, making the API human-friendly as well. Further, we can use Adaptive Web Design to make the best possible experience for all types of browsers and devices.This kind of solution has some risks and technical issues related to it though. And it is not a silver bullet.”(by Gustaf Nilsson Kotte)

PhiloWeb panel. “Philosophy” of the Web – Larry Masinter’s presentation at PhiloWeb 2012 (WWW2012) “Philosophy of Web Architecture” TAG panel. Lyon, April 17 2012.

WebPack– “I would like to introduce the term WebPack. A WebPack is a shareable implementation of link relations, media types and other types that provides a client application with sufficient semantics to be able to communicate with a Web API. Depending on how the semantics are shared, a WebPack may be used in a RESTFul (level 3) or Hypermedia API, or it could be used in a HTTP based API. It should never be required to use an API’s WebPack to consume the API. The WebPack is simply there to make it easier.” (by Darrel Miller)

Resource identification is not a REST invention – “Roy makes a case for backward compatibility on the web here: just don’t blur the URL with version information or other attributes that (quickly) change over time. He could have just stated “You know, URLs aren’t backward compatible if you include short-lived info like version numbers and such. So just don’t” but a dissertation needs to be a certain size, and they aren’t famous for being concise”

REST, Hypermedia, and the Future of Enterprise Web APIs – “While most people discussing REST focus on its use of URIs and HTTP methods, one of the fundamental contributions Fielding made in his work is the addition of hypermedia as a design element. Instead of hard-coding client applications to know ahead of time about all the possible remote calls, all the possible arguments and the order in which they must be executed, Fielding created a model where this information is supplied to the client in a machine-readable form at runtime within server responses.” (by Mike Amundsen)

Google Bot now crawls arbitrary Javascript sites – “Just spotted something while looking through Apache logs: 66.249.67.106 … “GET /ajax/xr/ready?x=clcgvsgizgxhfzvf HTTP/1.1″ … This is an ajax request issued from document.ready() callback of one website’s pages. This means that the bot now executes the Javascript on the pages it crawls. The IP of 66.249.67.106 is crawl-66-249-67-106.googlebot.com and the A record is a match, so this is in fact a Google Bot.”

HTTP/2.0 proposal – This page tracks proposals for the HTTP/2.0 work.

RESTful services as intelligent websites – “Thinking of RESTful services as intelligent websites helps drive our architecture decisions towards simplicity, discoverability and maximum use of the HTTP protocol. That should help us design services that are easier to use, debug, evolve and maintain. In this post I’ll try to address a few important aspects of RESTful services, considering them as intelligent websites. We might need more formal specifications in some cases, but this is hopefully a good start.” (by Bertrand Delacrétaz)

REST definition and its place within Enterprise Integration– “It’s not my intention to invalidate REST. It is my intention to really get behind its definitions, and its benefits, and see where those can be useful for Enterprise Integration. Call me narrow-minded but that’s all I’m interested in at the moment. The use of REST for the web? Not my area of expertise, but I believe REST is already widely implemented there. I think I have done a fair amount of research in order to find out what REST really is about – I even found that one if its pillars, CRUD, isn’t part of REST. It got added to it at some point, certainly not by Roy Fielding himself. Is REST useful for Enterprise Integration? Certainly not on the wide basis that Enterprise integration must operate on: multi-channel, multi-message, multi-device, multi-platform, multi-industry. In short: no, absolutely not.” (by Martijn Linssen)

The API-ificiation of software – and LEGOs – “So what does all this mean? Client-server software was replaced by on-premise Web-based apps, which are in turn being replaced by cloud/SaaS solutions. Perhaps the next generation of software will be solutions composed from these APIs/services. All of these exciting startups are proving that developers need — and want — these services. But ultimately, building complete solutions might require a LEGO-like construction kit. Is the future of software about Lightweight Enterprise Gadget Orchestration? Perhaps, there is even an opportunity for someone to provide an Interface Builder (remember NextStep?) that can natively access the myriad of emerging SaaS/APIs.” (by Robin Vasan)

So you want to offer a public API … – “You are awesome. Your startup just came up with a cool new piece of tech. Others might want to use it as well. The best way to do that is offering it up as a service – a RESTful API even. Hey, it made Twitter famous. Surely it will help you gain some traction as well … Might even make you some money! Now we’re talking! So … what goes into making an API?” (by Swizec Teller)

BAD HTTP API SMELLS: VERSION HEADERS – “One thing I didn’t cover in my previous rant on HTTP API versioning is an anti-pattern that I’m seeing a disturbing number of APIs adopt; using a HTTP header to indicate the overall version of the API in use. Examples include CIMI, CDMI, GData and I’m sure many more.” (by Mark Nottingham)

Don’t use HTML as the Media Type for your API – “Render one hypermedia type for your human consumers (HTML) and another hypermedia type for your machine consumers (HAL). Conneg (see HTTP’s Accept, Content-Type, Vary headers) should be relatively easy to leverage for this with a decent development stack.” (by Mike Kelly)

The necessity of hypermedia RDF and an approach to achieve it – “This paper will give an overview of the practical implications of the HATEOAS constraint of the REST architectural style, and in that light argue why hypermedia RDF is a practical necessity. We will then sketch a vocabulary for hypermedia RDF using Mike Amundsen’s H Factor classification as motivator. Finally, we will briefly argue that SPARQL is important when making non-trivial traversals of Linked Data graphs, and see how a bridge between Linked Data and SPARQL may be created with hypermedia RDF.” (by Kjetil Kjernsmo)

REST and Shared State Between Client and Server – “We share state between client and server all the time. Shopping carts, authentication and authorization status, what page a user is on, a step that a user just took and now we’re verifying, etc. There are tons of examples of where the client and server have to share state. But it is bad when *A* client shares state with *A* server. If server #432 in your server farm blanks out, and you lose the state for a client, then, yes, you have server affinity. Or stickyness. And that is a bad thing.”

HTTP API COMPLEXITY– “@dret: if your scenario is homogeneous and models are harmonized across participants, #REST is of limited utility for you…. Erik’s tweet just now reminded me of something I’d been wanting to write about for a while; complexity in HTTP APIs, and their effect on how you use the protocol.” (by Mark Nottingham)

Rethinking Web Service Development – “At the end of the day, we have to remember that API stands for Application Programming Interface and that these interfaces have to be programmed so humans can write to comsume them. One of Ruby’s main design points has always been to try to address human needs more than computer’s. As API designers/implementers, it seems important to adopt the same approach and consider who will use our interfaces. I think the discussion should focus more on what to value when defining web APIs, instead of arguing about how to implement APIs. Standardization is a great concept but a really hard to implement. And even with standards, we have to find a way to communicate with the API users to express what standards we follow and where to find the various entry points. Think about your API, how well does it communicate with your future API users, is it good enough for them to get excited? Is it good enough for them to create something amazing with it? If not, why not?” (by Matt Aimonetti)

CoAP and the REST– “Apparently it turned out that HTTP is not directly suitable so some clever people came up with the Constrained Application Protocol (CoAP). Now, CoAP is interesting as it is (besides HTTP) the only RESTful protocol I’m aware of. It is semantically aligned with HTTP and even has a canonical mapping to and from HTTP defined; also, people have started to document best practices around HTTP-CoAP mapping. But there are also some essential differences between HTTP and CoAP:” (by Michael Hausenblas)

Protocols in the kingdom of distribution – “The above is part of Jon Postel’s principle/law: be conservative in what you do, be liberal in what you accept from others. That is, always conform to the protocol – especially when you send data, but if you receive something you don’t understand – then skip it. This assumes that the other party can speak the protocol in a newer version than you, and you should design accordingly. A take-away though is that browsers parsing HTML were too lenient. If the HTML had an obvious parse error, then rather than producing an empty page the parser tried to fix the problem. The key here is that you should only be liberal as long as the message is still meaningful to you. Wrong HTML isn’t. This, and the fact that HTML is not an extensible protocol medium creates so many problems today.” (by Jesper Louis Andersen)

What does coupling mean to you? – “When talking about REST, the conversation usually boils down to coupling. REST enables distributed components to evolve independently over long periods of time, and it does this by constraining where coupling can occur.I’ve made this pitch a thousand times with the blind assumption that everyone had the same understanding of the term coupling. If I was to try and abstractly define coupling, I would say that, it is a measure of how changes in one thing might cause changes in the other. The confusion arises when you start to consider the best place to put the things that might change.” (by Darrel Miller)

Hacking PubSubHubbub – “PubSubHubbub is an open protocol of web hooks for notifications of updates to news feeds in a publish/subscribe framework. It is defined as a set of HTTP server-to-server interactions integrated into Atom and RSS extensions. Despite the odd name, PubSubHubbub is fairly straightforward to use for designing applications with a lot of information updates. Learn about the standard and open-source implementations and support software for PubSubHubbub.” (by Uche Ogbuji)

PubSubHubBub v0.4 – “The PubSubHubbub adoption is growing strong. There is not a week where a major publisher or a major subscriber eventually implements it. Yesterday, that was NewsBlur’s turn. At the same time, the current PubSubHubbub spec (0.3) is a bit rusty and presents a few issues that prevented more platforms to use it. The 2 most significant issues are the following: arbitrary content support, opening the door for private feeds. We recently worked on the version 0.4 of the spec, which, solves these problems.” (by Julien Genestoux)

Describing Resources, the Web Way – “while there is a describedby link relation type that has been registered in the IANA link relation type registry by POWDER for quite a while, this was not even considered as a possible way to handle the linked data problem. so maybe the lack of the inverse described was the problem, because it certainly would be more useful to be able to represent both directions of the same association? for this reason, there now is an I-D for registering The ‘describes’ Link Relation Type. ” (by Erik Wilde)

Evaluating REST Frameworks Part 1: A Maturity Model – “REST has been a very important topic of discussion for a while. This series attempts to provide a comparison of some current frameworks that support the development of systems that should be REST-compliant, regardless of the underlying protocol (typically HTTP). To begin, we need a criterion to perform this comparison and that’s what we’ll build in this first article by 1 Explaining what we understand about REST and what is it for. 2 Making a list of what is needed to create a REST compliant application. 3 Determining which features we may expect in a framework that supports REST development. 4 Proposing a maturity model we can use as a tool for evaluation/grading of existing frameworks. I’m not a maturity model fan, but they can be very handy for evaluation and comparisons since they define a usable criterion and in particular, a grade or level to assign.” (by William Martinez Pomares)

Fix 303 with client-side redirects – “I am trying to stay far away from the current TAG discussions of httpRange-14 (now just HR14). I did my time, years ago. I came up with the best solution to date: use “303 See Other”. It’s not pretty, but so far it is the best we’ve got. I gather now the can of worms is open again. I’m not really hungry for worms, but someone mentioned that the reason it’s open again is that use of 303 is just too inefficient. And if that’s the only problem, I think I know the answer. If a site is doing a lot of redirects, in a consistent pattern, it should publish its rewrite rules, so the clients can do them locally.” (by  Sandro Hawke)

HATEOAS 101: Introduction to a REST API Style (video & slides) – “Thanks to all who participated in the HATEOAS 101 Webinar this week. The video (~30 min.) and slides are below. Check them out for an introduction to the core principles, examples, and a look at the value of the approach for API providers and app developers.” (by Helen Whelan)

“REST API” or “HTTP API”? – “Bottom line: HTTP APIs are HTTP APIs. REST is about how things hang together. The terms aren’t interchangeable. In most technical discussions about interfaces or methods or URIs and most other implementation details, HTTP API is the right term.” (by Clemens Vasters)

RFC 6573: The Item and Collection Link Relations – “RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members.”

Home Documents for HTTP APIs – “This document proposes a “home document” format for non-browser HTTP clients.”

Indicating Details of Problems to Machines in HTTP – “This specification proposes a “Problem Detail” as an extensible way to carry machine-readable details of HTTP errors in a response, to avoid the need to invent new response formats for non-human consumers.”

Best Practices for HTTP-CoAP Mapping Implementation – “This draft provides reference information for HTTP-CoAP proxy implementors. It details deployment options, discusses possible approaches for URI mapping, and provides useful considerations related to protocol translation.”

apiary.io – “REST API documentation. Reimagined. It takes more than a simple HTML page to thrill your API users. The right tools take weeks  of development. Weeks that apiary.io saves.”

Siren: a hypermedia specification for representing entities 

hyperspider – “hyperspider is a declarative HATEOAS API crawler for node.js. Give it a list of url patterns, and it will recursively crawl your hypertext HTTP API, streaming back every matching endpoint.hyperspider is great for folks that want to create clean, granular, and self-documenting hypertext APIs, but avoid the latency of remotely fetching hundreds of tiny HTTP resources.” (by Jed Schmidt)

weblinking – “A javascript parser for RFC5988 Web Linking” (by Benjamin Carlyle)

stream-server – “Create streaming servers in your browser. Emulating peer to peer connections through a central proxy server”

Ramone – “A C# client framework for consuming HTTP/REST services” (by Jorn Wildt)

Events and publications

SOA with REST:Principles, Patterns & Constraints for Building Enterprise Solutions with REST – “Service-orientation has established a proven method for realizing a specific target state that has proven strategic value to many organizations. Achieving this target state requires that we apply service-orientation to a suitable distributed computing medium. This book demonstrates that REST is not only a suitable medium for building truly service-oriented solutions, but also that the service-oriented architectural model is a suitable (and often necessary) foundation for REST technology architectures to realize their full business potential.” (by Raj Balasubramanian, Benjamin Carlyle, Thomas Erl, Cesare Pautasso)

The REST API Design Handbook – “Designing and implementing web services APIs has become a common part of every software engineer’s job. The RESTful approach to web services design is rapidly become the approach of choice. Unfortunately, too few people have truly solid REST API design skills, and discussions of REST can become bogged down in dry theory.The REST API Design Handbook is a simple, practical guide to aid software engineers and software architects create lasting, scalable APIs based on REST architectural principles. The book provides a sound foundation in discussing the constraints that define a REST API. It quickly goes beyond that into the practical aspects of implementing such an API in the real world.” (by George Reese)

WSREST 2012 – The Third International Workshop on RESTful Design (WS-REST 2012) was held at WWW2012, on 17 April 2012, Lyon, France. Lots of interesting papers were presented, so take a look at the Program section! Also, take a look at Mike Amundsen’s report from the event.

WWW 2012 – The 21st World Wide Web conference was held in Lyon, France, from the 16th to 20th April. Again, check out the program and proceedings sections to see the papers presented at the event!

HTTPBis at IETF84 – Mark Nottingham has a nice overview of the HTTPBis WG meetings at IETF84.

ICWE 2012 – The 12th International Conference on Web Engineering was held in Berlin, Germany, on July 23rd – 27th. Check out the program to see the list of presented papers!

WWW 2013 – The 22nd World Wide Web conference will be held in Rio de Janeiro, Brazil, from 13th to 17th May 2013. See the call for papers if you are interested in submitting work!

REST Fest 2012 – The annual REST Fest event is being held from September 13th – 15th in Greenville, SC, USA. “REST Fest is an unconference developed by Mike Amundsen and Benjamin Young. Our objective is to give people interested in REST, Hypermedia APIs, crafting web service APIs, or any related topics a chance to get together in an informal setting to share ideas, trade stories, and show examples of current work.”

REST: Advanced Research Topics and Practical Applications – Call for Chapters – Call for chapters for the next REST book: ” In this book we gather contributions on applying REST beyond public Web services (e.g., in pervasive computing applications, cloud computing environments and integrated enterprise architectures) and on results of recent research studies for doing so. The goal is to go beyond the basic understanding of what REST is about as an architectural style and collect emerging and established design patterns to provide valuable guidance for the reader. The book will both give a clear, principled description of REST and show how it has made an impact in the state of the practice as well as provide an outlook on ongoing research advances. Readers will find a good starting point for making sense of REST, its design constraints, advantages and disadvantages, as well as a broad collection of novel practical application case studies where using REST has made a difference. The book is intended for service designers, information systems architects and anyone interested in learning the current state of research and application of the REST architectural style.”

Interesting tweets

@dret: “#REST experiment: assign random URIs to all resources. does everything still work? good! did something just break? you found some coupling.”

@mikekelly85: “The REST API ecosystem suffers because ‘thought leaders’ hugely overcomplicate the story of how-it-should-be-done, and so people switch off.”

@dret: “an identifier isn’t necessarily a link (i.e., not actionable), but a link always is an identifier. make sure you always know the difference.”

@clemensv: “Simpler and more compact than JSON? Entity-less HTTP. All props/payload in headers prefixed with “P-“. Just made that up, this is the spec.”

@dret: “the biggest #REST anti-pattern: hardcoding URI templates in clients. the biggest #XML anti-pattern: hardcoding namespace prefixes.”

@dret: “a REST resource is self-describing data that allows clients to understand the links to and semantics of interactions with related resources.”

@mikekelly85: “HTTP should be focused on establishing semantics that make useful contributions to the intermediary-processability of interactions.#fkPATCH”

@dret: “the more general question is: if #RESTframeworks require one media type per controller, are they encouraging not-so-great design patterns?”

@dret: “media types identify both a conceptualization and a serialization, and that mix make them somehow hard to understand and apply. #REST”

@mikekelly85: “HTTP should be designed to do nothing but facilitate useful intermediary mechanisms.”

@darrel_miller: “Hey UI control vendors, it’s time to start learning about REST, media types and link relations. There’s gold in them thar hills.”

@dret: “#CRUD may almost be an anti-pattern for#REST, unless you look at it from the “manage workflow-driving business documents” perspective.”

@dret: “action URIs are ok as long as interactions with them are stateless; POSTing to them cannot imply what resource “they belong to”. #REST”

@dret: “you don’t need a link relation type for each interaction type. HTTP methods and/or transferred state can allow multiple interactions.#REST”

@dret: “in RDF, URIs are opaque identifiers with no semantics; in REST, they are handles for interactions and encode those semantics.”

This Week in #REST – Volume 43 (Mar 7 2012 – Apr 3 2012)

This is Volume 43 of This week in REST, for March 7 2012 – April 3 2012. 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

What’s next for HTTP? – See the links in this post for presentations about the future of HTTP/1.1 and /2.0 (WAKA, SPDY, etc). “We had two great meetings of the HTTPbis Working Group in Paris this week — one to start wrapping up our work on HTTP/1.1, and another to launch some exciting new work on HTTP/2.0.” (by Mark Nottingham)

PubSubHubbub Core 0.4 Working Draft – Julien Genestoux has started revising the PSHB spec based on feedback. See forum discussion thread here.

Loading Data From The API – How Much Is Too Much? – “I’m really liking what’s coming together with this Hypermedia-ish API. So many ideas and approaches are starting to come into focus. Like this one: how much structured data do I pass on the initial load of the API?” (by Rob Conery)

RESTful services as intelligent websites – “In this post I’ll try to address a few important aspects of RESTful services, considering them as intelligent websites. We might need more formal specifications in some cases, but this is hopefully a good start.” (by Bertrand Delacrétaz)

Test Your RESTful API With YQL – “When saying earlier that building an API can be complex, I rather meant that it is difficult to get it “right”. So how can you find out if you got it right or not? In this article I am proposing to use YQL as a tool to assess the quality of your RESTful API, in terms of following best practices and standards.” (by Sebastian Spier)

Automated Documentation for REST APIs – “From time to time, people who have a REST API ask me about automated documentation. There’s no one right answer, so I’ve been meaning for ages to write an article about what the options are.” (by Peter Gruenbaum)

Rest test test – “A native in-browser tool for testing REST/CORS services.” (by Jeroen Ooms)

API jobs – Web engineering jobs aggregation page that focuses only on jobs concerning APIs.

URI templates – URI templates is now an RFC (standards track).

The ‘profile’ Link Relation Type – “This specification defines the ‘profile’ link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined to not alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics that are associated with the resource in addition to those defined by the media type and possibly other mechanisms.”

PATCHing AtomPub – “one of the advantages of PATCH is that updates can use any kind of diff format that is deemed appropriate for the application, and thus (in case or larger resources, for examples) it may be desirable to use the general patterns established by AtomPub, but to allow updates by PATCH, maybe in addition to PUT, or as the only allowed method for updates. but what would it take to PATCH-enable AtomPub? there are (at least) three possible answers, and i am curious to see whether there is some community consensus for the best one.” (by Erik Wilde)

REST Design Philosophies – “instead of best practices everybody agrees on REST has a number of distinct schools of thought or design philosophies; neither inherently good nor bad, neither obviously right nor wrong; each with its champions and detractors.I’ll attempt to describe four of these design philosophies without claiming any authority in the matter. Others would likely name and describe them differently. I decided to draw quick sketches instead of painting full portraits, capturing the distinctive features and worrying less about getting every detail right.” (by Ferenc Mihaly)

HATEOAS Openstack Keystone – “Of all the principals of REST, perhaps the most overlooked it Hypermedia as the Engine of Application State, or HATEOAS. This term tries to encapsulate several concepts together, but the primary is the principal of discoverability.” (by Adam Young)

REST and the Art of Protocol Design – “RESTful protocol design is a topic more appropriate for a book than a blog post. Despite the catchy title my goal is very modest. I would like to show you that even limited protocol design knowledge can help you understand the essence of REST and the reasoning behind many of its best practices.” (by Ferenc Mihaly)

REST Layers and REST Applications – “in an attempt to better understand what and why people are trying to accomplish when they try to describe REST, here is a first approach to more cleanly layer the issues, see what’s already around, and try to figure out what value could provided by some format/technology for each layer. we are actively working in this area because we simply need something that will allow service providers to describe (and by that we mostly mean document) their services. our platform allow customers to define and expose REST services, and when they do this and want to point, for example, external partners at these services asking them to develop clients, instructing them to tell your external partners to follow their nose just doesn’t quite cut it.” (by Erik Wilde)

You can’t achieve REST without client and server participation – “Recently I have been having a bunch of discussions around REST and whether or not the client participates in the RESTfulness of a system. Until now I’ve been saying that REST is confined to the server. I now realize that was wrong. Having a server which adheres to the constraints without clients that obey the same constraints will NOT yield the full benefits of REST.” (by Glenn Block)

Hypermedia Client Maturity Model – “One area that has not had as much attention paid to it is that of the client. Although it is necessary for a service to be RESTful in order to build a system that exhibits RESTful characteristics, it is not sufficient. The client needs to behave RESTfully or the coupling that the server tried to avoid will be re-introduced.” (by Darrel Miller)

Upgrading WebHooks To Be More Useful – “We should upgrade WebHooks so that they can be created by submitting a form/template of the callback request to be generated. This will allow users to connect APIs together arbitrarily without having to wait for providers to do the work to make it happen.” (by Mike Kelly)

http://httpstatus.es/  – “Database of HTTP status codes with their IETF and Wikipedia descriptions.”

Discussion groups

Does the client contribute to the RESTfulness of an application? – Longish, but very interesting discussion on whether client components contribute to the RESTfulness of a hypermedia system.

Changing the httpRange-14 resolution – There has been a number of discussion on the W3C TAG list about amending the httpRange-14 issue resolution.

The HTTP vs SPDY debate – There’s also been a number of discussions on the IETF HTTP mailing list about HTTP 2.0 and SPDY’s role in it.

Interesting tweets

@savasp – “If one wishes to change the Web, one first needs to understand it! I happen to believe that the Web-as-a-platform is absolutely fine as is!”

@DanaDanger – “HTTP response codes for dummies. 50x: we fucked up. 40x: you fucked up. 30x: ask that dude over there. 20x: cool.”

@dret – “#REST design is about resources and links and about these only; #URI patterns are 100% a deployment issue and are not part of the design.”

@dret – “new #REST rule: no, you cannot play with your URIs until you have designed all of your media and link relation types.”

@mamund – “wonder if anyone has done the work Fielding describes here: http://g.mamund.com/zebnj there might be thesis/dissertation material. #REST #Web”

@fuzzyBSc – “#REST and #SOA integration differ in that SOA creates a service to be the integration point while REST creates a media type to be that point”

@dret – “I love the smell of RPC in the morning.”

@dret – “nobody says “they are calling a web page” or “calling a form API”; why do many “#REST” services assume it makes more sense outside of HTML?”

@dret – “in the same sense as there is the “dark web”, there are “dark web services”, which are all those ones which are not properly linked. #REST”

@dret – “do you design your web site in terms of what users can enter in the address bar? then why should it makes sense for web services? #REST”

@dret – “the three pillars of #REST: data model (what to expect), processing model (how to process), operational model (where to go and why and how)”

This Week in #REST – Volume 42 (Dec 30 2011 – Mar 6 2012)

This is Volume 42 of This week in REST, for December 30 2011 – March 6 2012. 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! And I’m sorry for not blogging more often – I’ve been very busy over the last few months.

Around the Web

Fitful Sleep – A Savage Chickens cartoon about the 404 status code.

Civilisational HTTP Error Codes – “To be truly useful, HTTP error codes need to take into account possible future issues.”

RFC for the 7XX Range of HTTP Status codes – Developer Errors – “There are many ways for a developer to screw up their implementation, but no code to share the nature of the error with the end user.We humbly suggest the following status codes are included in the HTTP spec in the 7XX range.”

STOP SOAP

When “identification” and “representation” fight, who wins? – “Let’s now enter the fantasy world where “resource”, “identification”, and “representation of” have meanings consonant with what is found in the Web architecture documents RFC 3986, the HTTPbis draft (I’m looking at version 18), and AWWW. To make any sense of these documents the words have to be assumed to have something close to their ordinary language meanings (which are rather squishy), since they are otherwise effectively undefined.” (by Jonathan A Rees)

Entities and actions – “hypermedia designs focus on the actions taking place in the problem domain. things like “get a list of customers sorted by date” and “allow users to filter the order list by sales region” and “allow selected users to add new customers”, etc. are all actions. when implementing a system using these actions as the centerpiece, hypermedia designs select the appropriate affordances (within the selected media type) and map those affordances to the identified actions.” (by Mike Amundsen)

Building a Modern Web Stack for the Real-time Web – “The new protocols are here, but the supporting “back office” architecture requires a serious update: SSL is becoming the default, streaming is no longer an option, and long-lived persistent connections are in. SPDY is gaining momentum, and I have no doubts that in the not so distant future it will be an IETF approved protocol. Similarly, ØMQ is not the only alternative for internal routing, but it is definitely one that has been gaining momentum. Fast HTTP parsing and routing is simply not enough to support the modern web use cases. Likewise, punching “TCP holes” in our infrastructure is not a viable long-term solution – in 2012 we should be asking for more. Yes, I’m looking at you Varnish, Nginx, Apache and friends.” (by Ilya Grigorik)

S: A Scripting Language for High-Performance RESTful WebServices – a presentation for the paper by the same name, from the 17th ACM SIGPLAN Symposium on Principles and Practice.

Building Hypermedia Web APIs – “Many of the media types we use nowadays for building Web API’s such as JSON or XML don’t have a built-in concept for representing hypermedia links as HTML does with links and forms. You can leverage those media types by defining a way to express hypermedia, but again, it requires client to understand how the hypermedia semantics are defined on top of those. Other media types like XHtml or ATOM already support some of the hypermedia concepts like links or forms.” (by Pablo M. Cibraro)

WS-* vs REST for the Internet of Things – “I wanted to discuss this choice and base it on data, first looking at quantitative results (e.g., performances of REST vs WS-*) but then also getting some qualitative data: does REST really makes it easier to build upon smart things? WS-* and REST have previously been compared with respect to performance and features, but no work has been done to elicit the developers’ preferences and programming experiences in an Internet of Things context…”

JSON, HTTP and data links – “… I sensed that the community at large is ready for the next aspect of the Web. A scalable, machine-targeted way to realise a global dataspace. And it’s happening as we speak.Take JSON and HTTP (some use REST for marketing purposes) and add the capability of following (typed) links that lead you to more data (context, definitions, related stuff, whatever).And here are the three current contenders in this space.” (by Michael Hausenblas)

HTTP at a glance – “Many web developers using HTTP don’t think about the protocol itself. This site should provide a basic understanding of HTTP 1.1 and ease the development of web applications that use HTTP.This “HTTP explanation” is an incomplete, simplified, human-readable summary of the full specification.”

Object Network -mapping the web – (talk) “Duncan Cragg will give a talk for the London Android User Group on Object Network. Instead of writing a whole new, dedicated HTTP API to your site, publish your data using common JSON object formats, and link your data up, both within your own sites and to other sites. Become part of a global Object Network! See http://the-object.net&#8221; (by Duncan Cragg)

REST vs. Websockets, Oh My – “There is an entirely absurd discussion going on about “REST vs. Websockets”, predictably claiming that in the long term, REST will be succeeded by Websockets. This is stupid on many levels. I’ll try to be brief” (by Stefan Tilkov)

Additional HTTP Status Codes – “This document specifies additional HyperText Transfer Protocol (HTTP)status codes for a variety of common situations.” (IETF document, by Mark Nottingham)

HTTP is not a transport protocol, HTTP is not RPC – “This has deep implications in your API design. Once you accept that the thing that you are exposing is an HTTP resource which clients interact with via the uniform interface and not a class with standard OOP methods, you design them differently. Your APIs become a gateway where HTTP concerns are addressed and then work is delegated off to the business domain rather than being part of the business domain.” (by Glenn Block)

Resource Profiles – “in our work on RESTful services, we have repeatedly run into the situation where we want to have a runtime mechanism how a resource can represent the fact that it follows additional constraints and/or rules. creating media types at runtime is not such a great idea, and it would also not allow us to represent the fact that a resource is still using a representation based on some media type, but also can be treated according to additional constraints and/or rules. a profile mechanism would be a good way of doing this, and thus we would like it to become a recognized link relation type.” (by Erik Wilde)

Hypermedia Analysis – “This project tries to establish a baseline concerning HATEOAS deployment on the Web, that is, collecting a statistically relevant sample of representations offered by so called RESTful APIs and determine to what degree they ‘contain hypermedia’. We will do this in two phases:First, we will use the Programmable Web API to determine target APIs and retrieve representative samples of representations from those APIs in an automated fashion.Second, we will, manually, evaluate the repository of API representations and determine how to measure the ‘degree of hypermedia’ used.”

ROCA Resource-oriented Client Architecture – A collection of simple recommendations for decent Web application frontends – “ROCA is an attempt to define a set of recommendations – independent of any particular framework, programming language, or tooling – that embodies the principles of what we consider to be good web application architecture. Its purpose is to serve as a reference, one that can be implemented as is or be compared to other approaches to highlight diverging design decisions.”

Someone Save Us From REST – “REST is a fascinating and illuminating set of ideas and, as it turns out, is a handy guideline for effectively preparing an API. As it turns out – digging deep into what you think REST means runs the perils of digging deep into any religious philosophy: adherence turns into devotion.I like REST like I like any [Religious Doctrine]. I dislike the people who drop Fielding Passages in some apostolic attempt to save my non-RESTful soul. My relationship with REST is a personal one and, frankly, I like to think REST guides me in my application development walk in the way Fielding intended for me, and my web app.” (by Rob Conery)

POST-PUT-PATCH illustrated – “the announcement that Rails is adding support for PATCH has caused some gum-flapping on the Inter-Tubes and this all came up in a recent convo w/ some of my colleagues today. it turned out most of them don’t have much experience in “talking HTTP” but know T-SQL really well. so i decided to illustrate the differences between HTTP’s POST, PUT, and PATCH methods using simple T-SQL examples.” (by Mike Amundsen)

REST will stay – you can wash your SOAP away – “REST web services will stay. It is a bad thing to predict future of technology. But I am ready to bet on this one. REST will stay. It will stay because of multiple reasons, and today I am going to give you mine.” (by Samik Chakraborty)

Afforded agents – “data needs to be “afforded” – we need to see not just the “what” in a message, but also the “how.” i appreciate the work the Semantic Web community has done in order to get folks thinking about the idea of messages having “meaning”; that’s great. unfortunately, the same community has not done well in getting folks thinking about the idea of messages having “affordance” – use-ability built right into the data itself.” (by Mike Amundsen)

ql.io – Consuming HTTP at Scale – presentation on ql.io from the Node Summit , Jan 24, 2012

Nobody Understands REST or HTTP – “The more that I’ve learned about web development, the more that I’ve come to appreciate the thoroughness and thoughtfulness of the authors of the HTTP RFC and Roy Fielding’s dissertation. It seems like the answers to most problems come down to “There’s a section of the spec for that.” Now, obviously, they’re not infallible, and I’m not saying that there’s zero room for improvement. But it really disappoints me when people don’t understand the way that a given issue is supposed to be solved, and so they make up a partial solution that solves their given case but doesn’t jive well with the way that everything else works. There are valid criticisms of the specs, but they have to come from an informed place about what the spec says in the first place.Let’s talk about a few cases where either REST or HTTP (which is clearly RESTful in its design) solves a common web development problem.” (by Steve Klabnik)

Discussion groups

Rechartering HTTPbis – epic thread on HTTP 2.0 and SPDY “When this effort was started we took great pains to make it clear that we weren’t working on a new version of HTTP, because there wasn’t implementer support to do so and we wanted to focus upon interoperability and security.That’s clearly changed in the intervening time; two major browsers have implemented SPDY, a non-textual serialisation of HTTP’s semantics, and there are now several other implementations as well (full disclosure: including an experimental one in Python by yours truly).I’ve been talking to a number of folks — including those implementing SPDY, as well as HTTP implementers and the W3C TAG — about this recently. There seems to be broad agreement that the time is ripe to start work on a new version of HTTP in the IETF, and that it should happen in this Working Group.”

Where should I POST to? – “Here are different ideas to create a comment:- “POST on /posts/43” – According to the definition of POST [1], this should be acceptable under “annotation of existing resources”.- “POST on /posts/43/comments” – According to the definition of POST [1], this should be acceptable under “posting a message […]”The question: which one(s) of the above seem acceptable, which one is “best”?”

Formats with native hypermedia support – “I’m trying to create a list of formats with native hypermedia support (HTTP)that goes beyond just links supporting a GET.. So far my list is quite shortand I can’t believe that that’s all:- HTML (GET/POST/PUT)- Atom & AtomPub (GET/POST/PUT/DELETE)- WSDL (GET/POST/PUT/DELETE)- WADL (GET/POST/PUT/HEAD/DELETE)- Collection+JSON (GET/POST/PUT/DELETE)”

Related resource: Inlined or linked – “It sounds like the related resource may be either linked or inlined – whatever the server decides. I can understand the approach if the media type explicitly says that there should be either a link OR an inlined resource. But when it says there should be an inlined resource and the server decides to return a link to it, then the server is not implementing the media type anymore. And vice versa, when media type says there should be a link, but the server returns an inline target resource.”

Design styles: OO/URIs compared to Media Types – a lengthy discussion about APIs: “I wonder if you (and anyone else on this list) would be wiling to talk about why you favor OO-URI design over message design (or vice-versa, if that’s the case)?Note I am not at all interested in what is “right/wrong” or “what Fielding sez should be done”, etc. I am most interested in the preferences people have and why they have them. This would help me a great deal in some explorations in which I am currently involved.”

either strengthen or retract httpRange-14(a) – “Personally I feel that the (a) clause of the httpRange-14(a)resolution MUST NOT stand as it is. It must be either strengthened orretracted. It is terribly confused, does not solve the problem the resolutionclaims to solve, and has divided the community in verydestructive ways.”

HATEOAS: concise description – “I am trying to get a clear and concise understanding of HATEOAS, and I am by no means an expert WRT REST. Can anyone suggest an equally enlighenting blog/article WRT HATEOAS?”

Introduction | The Object Network – “Let’s presume for a second that this succeeds, what could I then do that couldn’t do today. Or what could I do more easily than I could today?”

Review: http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt – discussion about the SPDY protocol proposal.

Idempotent partial updates – interesting thread about PUT and PATCH for partial updates. “HTTPbis has amended the semantics of PUT to be unambiguous in its prevention of partial updates. I cannot understand the rationale behind this change, and I have a couple of questions for the group:”

[p3-payload] Media-Type — Two Values, One Cup Anti-Pattern? – “Early media types constrained themselves strictly to describing the format(syntax) of the representation (image/png, application/xml). As time woreon, though, media types sprang up that contained both syntactic & semantictype information (see the application/vnd.openxmlformats-*+xml series foran example). Negative ramifications seem obvious (add json, yaml => m*ntypes, parsing, querying, …); in fact, in other contexts (DB & objectfields), placing two values into a single cup/bucket is such a basicmistake with such obvious drawbacks, it’s rarely even discussed as an issue.Does anyone else see this as a problem?”

Events and books

“APIs: A Strategy Guide – Creating Channels with Application Programming Interfaces” – New book from O’Reilly: “Learn about the rise of APIs and why your business might need one. Understand the roles of asset owners, providers, and developers in the API value chain. Build strategies for designing, implementing, and marketing your product. Devise an effective process for security and user management. Address legal issues, such as rights management and terms of use. Manage traffic and user experience with a reliable operating model. Determine the metrics you need to measure your API’s success” (by Daniel Jacobson, Greg Brail, Dan Woods)

Interesting tweets

@fielding – “@robconery Partial PUT violates the HTTP standard, not REST. Broken hacks should be fixed before deployment, regardless of how it is argued.”

@blowdart – “There’s only one thing as far as I am concerned that HTTP 2.0 can do. FIX THE SPELLING OF REFERRER.”

@serialseb – “Design your media types for extensibility, versioning is not the right change control mechanism at the scale of the web.”

@duncancragg – “My HTTP/2.0 list has just 2 items: asynchronicity and bidirectionality. Which is really just ‘POST requests that look like GET responses'”

@dret – “wondering how much confusion is caused by #REST calling clients “applications”, and many others talking about “application servers”.”

@mamund – “dist-net comms distilled: each request is 1) mutable/immutable? 2) safe/unsafe? 3) idempotent/non-idempotent? 4) navigation/transclusion?”

@dret – “interested in #REST engineering positions at @EMCcorp in Pleasanton, CA? we’re hiring! 2012 summer interns are welcome to apply as well.”

@fielding – “Please don’t argue against principled design on the basis that “real developers” don’t care about design principles. They have no choice.”

@aphethean – “If I had to have a #REST motto, I think I’d like mine to be “resources are cool, so are URIs””

@kellabyte – “@ICooper +1 HTTP API. REST may not even fit for many probs, nobody is saying everything should be REST. Just don’t mislabel what you built”

@howard_dierking – “another day, another post describing “RESTful URLs”…sigh…I’m going to have to change all RESTbugs URLs to GUIDs just to make a point”

@dret – “wondering how many document types average media types define. #HTML: 2; #Atom: 2; #AtomPub: 2. does that translate to: usually few? #REST”

@mikekelly85 – “Web intents as a concept is fine, but why not re-use what we already have? i.e. just use <link> and @rel instead of <intent> and @action”

This Week in #REST – Volume 41 (Nov 17 2011 – Dec 29 2011)

This is Volume 41 of This week in REST, for November 17 2011 – December 29 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! And…

… HAPPY NEW YEAR! :)

Around the Web

HTTP status cats – (Lol)cat images for different HTTP status codes. And the follow-up: HTTP status dogs.

Evolution of the Web – “The Web is not finished. Evolution is necessary to adapt to new requirements, add new features and fix problems in response to changes in circumstances, applications, and user needs. How does evolution happen in a way that does not break it? Traditional means of evolution of formally defined languages, protocols, and standards do not fit well with the way in which the Web evolves. Unmanaged evolution results in diminishing the interoperability of components, a cost to all which must be weighed against the benefits of evolution. There are a number of issues that need to be addressed to help achieve the goal of global interoperability in an evolving world. This document analyzes some of the issues and makes recommendations for best practice.” (by Larry Masinter)

Understanding URI Hosting Practice as Support for Documentation Discovery – “This document defines version 1.0 of the URI Documentation Discovery protocol, or “UDDP 1.0″. The protocol is a way to ask the agent that controls resolution behavior for a URI what it thinks the URI means or should mean.” (by Jonathan A. Rees)

WebSockets versus REST… fight! – ” On 8th December 2011, a little known (but growing in awareness) standard called “WebSockets” was upgraded to W3C Candidate Recommendation status. … After reading up about the standard in detail and absorbing the various online discussion around it, it is becoming increasingly clear to me that this standard is going to steal a large chunk of mind share from RESTful web services. What I mean is that there will come a stage in product development where somebody will have to ask the question: Right guys, shall we use WebSockets or REST for this project?” (by Nathan Evans)

SPDY: What I Like About You. – “tl;dr; Faster is all well and good (and I mean that!) but I’m going to make a long argument that SPDY is good for the Internet beyond faster page load times. Compared to HTTP, it is more scalable, plays nicer with other Internet traffic and brings web security forward.” (by Patrick McManus)

Action URIs – “anybody doing non-trivial things with REST sooner or later runs into interactions beyond the simple CRUD (create/read/update/delete) operations. there often are cases where operations might be tied to a specific resource (or mainly to that resource), and then the question is how model this in a RESTful way. a pattern that is seen frequently is the action URI, which is a URI that specifically represents one action on one resource.” (by Erik Wilde)

REST : ‘inverted’ architecture – “history has shown that the HTTP protocol is a very flexible protocol and that not all implementations need to follow the example provided by Fielding in order to meet the needs of users. for example, RPC over HTTP works just fine for many cases; esp. those that do not require system stability on the scale of years/decades.” (by Mike Amundsen)

Write Better Cukes With the Rel Attribute – “The other day, I was working on some Cucumber features for a project, and I discovered a neat technique that helps you to write better Cucumber steps. … When doing research for my book on REST, I’ve been doing a lot of digging into various standards documents. And one of the most important attributes from a REST perspective is one that nobody ever talks about or uses: the rel attribute.”(by Steve Klabnik)

requestb.in – The awesome postbin webapp got upgraded and polished. “RequestBin lets you create a URL that will collect requests made to it, then let you inspect them in a human-friendly way. Use RequestBin to see what your HTTP client is sending or to look at webhook requests.” (by Jeff Lindsay)

Mobile API Design – Thinking Beyond REST – “This article explores the problems of optimising REST APIs for mobile device performance, and suggests a way of allowing clients to request alternate representations.” (by Dan Fairs)

Restfuse 1.0.0 – A Library For Easy REST/HTTP Integration Tests – “EclipseSource has released the first stable version for an open source JUnit extension that automates testing of REST/HTTP services. Restfuse is a set of JUnit annotations that, along with the respective HttpJUnitRunner, offer assertions against the response of an HTTP call. Both synchronous and asynchronous remote calls are supported.” (by Kostis Kapelonis)

Nutshell Definitions – “I try and distil a concept into a single word, or at most a short phrase, in order to understand it. This has been very useful to me in evaluating the merits of technologies and comparing them to others. Call these my trade secrets which I’m now sharing with you :-).OK, so here are some of my definitions of popular terms, each in a nutshell:” (by Ganesh Prasad)

Ruby On REST: Introducing the Representer Pattern – “This post introduces the new Roar gem, a framework-agnostic RESTframework for Ruby that puts focus on object-oriented RESTdocuments.” (by Nick Sutterer)

Media Types in RESTful HTTP – “A topic that comes up again and again in discussions about RESTful design is what kinds of media type to use. I’ve changed my mind about this a few times, often enough so that I believe it makes sense to write a bit about my current thinking on this. (A “media type”, should you happen to wonder what I’m talking about, is a specific format with a well-defined name, in this context represented in the form of a media type identifier such as application/xml or text/html or application/json.” (by Stefan Tilkov)

Best Practices for HTTP API evolvability – “One thing we know is that these APIs will change, so what can we do at a technical level to deal with these changes as they occur? The main moving parts of a HTTP API are * The generic semantics of methods used in the API, including exceptional conditions and other metadata * The generic semantics of media types used in the API, including any and all schema information * The set of URIs that make up the API, including specific semantics each generic method and generic media types used in the API. These parts move at different rates.” (by Benjamin Carlyle)

JSON Linking with HAL – “We need a media type (the HTML of machines), not another XLink. We need a general purpose media type, which extends JSON, that can be used as a standard way to represent a resource and its relations to other resources on the Web.It’s very important, particularly because we are talking about JSON, that this media type be simple in its design.” (by Mike Kelly)

Announcing ql.io – “ql.io is a declarative, evented, data-retrieval and aggregation gateway for HTTP APIs. Simply put, this is our answer to the pain points that I recently described in my APIs are a Pain post.” (by Subbu Allamaraju)

Introduction | The Object Network – “It’s interesting to compare the current growth of Web APIs with the early growth of the Web itself. To save you jumping those links: the Web dramatically beats the APIs. I believe that the most likely cause of such relatively slow growth (in what should be a booming ecosystem) is that each API forms a closed silo and cannot benefit from any network effects. Every API is different and there are no links between them. There usually aren’t any links within a silo. You can’t even use a given API without first consulting the documentation. The Object Network is designed to fix this, with linked-up JSON in common formats. This will allow easier mashing, sharing and cacheing of data and allow client code to be shared and reused.” (by Duncan Cragg)

Discussion groups

Oh, please no. JSON is a data format. If you want a hypertext format there’s HTML for that. – A really long and interesting discussion concerning links in JSON.

Rails 3.2 and PATCH – another long and interesting thread on PUT and PATCH semantics.

Restoring PUT and DELETE – “Can we revisit the decision to remove the PUT and DELETE verbs from HTML5.”

Discussion points on HTTP “evolutions” – “HTTP is now used more and more to deliver data to web application, usuallyin small chunks. One result is that people wants to optimize the use ofHTTP, or HTTP itself (by modifying it, or modifying the underlyingtransport) to reduce latency, bandwidth usage etc…Another aspect is that Web content is more and more delivered toauthenticated users, meaning that the authentication part and the contentretrieval may be subject to snooping or worse, impersonation. Firesheep is a good example of a simple way to doreplay attacks when authentication is done in the clear through cookies. Areaction to that is to use https which has its own set of issues.”

Negotiated private cache storage allocation – “Is anyone aware of any proposals that extend HTTP to allow servers andclients to negotiate client-side storage allocation for client-side(private) caches?Basically, I’m looking for a way for a server to indicate how muchstorage should be allocated for caching responses from a particulardomain name, and possibly also for the client to be able to indicatehow much allocation was actually possible.”

weighting and boundaries of evolvability and loose coupling? – “one major aspect of using hypermedia is loose coupling and evolvability. butwhere are the boundaries? which server-side changes may/may not affecthypermedia-aware clients?for example: as a human user, i can easely adapt to a change in a web shopsystem, e.g. when the order procedure include suddenly an additional step likeproviding an optional voucher code.”

service “definition” techniques – “Is anyone using something like WADL for service definition documentation? We’re(hopefully) going to have a collection of many services in multiple domains andwe’ll be expected to have a standard ‘template’ for defining/documenting aservice. I’m curious if anyone in an “enterprise” situation has run into thatand has any advice.”

Using # in link relations to distinct links of the same relationship – “Several times i came to the question, wheter to specify a relation with somekind of index to distinct links of the same relationship type. examples:

GET /products/canon

<category name=”canon” …><link href=”…” rel=”http://example.com/item#1&#8243; …/><link href=”…” rel=”http://example.com/item#2&#8243; …/><link href=”…” rel=”http://example.com/item#3&#8243; …/></category>”

Noob question – “I have a list of tasks resource (PATH: /tasks). What rules of REST will break ifI made /tasks return different result for different sign in users (It could be/users/1/tasks)? What is the disadvantage of that? Thanks.”

The “new media types are evil” meme – “I’ll give a few of thereasons using a generic media type is the better option… Is someone able to put together a similar list for the “new mediatypes are awesome” meme?”

REST = no interoperability! – “Allow me to try a debate that is a bit more opiniated than my normal posts:REST will never get any break-through in M2M scenarios due to it’s completelack of interoperability! [ducking for cover]”

REST is not about domain models – “If “REST is not about domain models” (as Glenn Block states it here:http://tech.groups.yahoo.com/group/rest-discuss/message/18117) how are wethen going to solve machine-to-machine scenarious where it is all aboutspecific domains? By not using REST? I know this is beating an old horse,but I still have issues with the idea of ignoring the domain of a system.”

Less REST, more Hypermedia! – “I think, it is time to push forward terms like “hypermedia service/API” or”hypermedia-aware client”. Instead of saying “hey i have a RESTful API”, tellthe people “i have a hypermedia API!”.”

Events and books

WSREST 2012 – WSREST is on again next year, find the CFP here.

ICSOC 2011 – This year’s ICSOC (International Conference on Service Oriented Computing) was held in Paphos, Cyprus. Have a look at the many interesting papers in the main program and workshops.

Building Hypermedia APIs with HTML5 and Node – a new book by Mike Amundsen “With this concise book, you’ll learn the art of building hypermedia APIs that don’t simply run on the Web, but that actually exist in the Web. You’ll start with the general principles and technologies behind this architectural approach, and then dive hands-on into three fully-functional API examples.”

Interesting tweets

@mamund – “breaking changes on the WWW is an anti-pattern; when the lifetime of a “API” for the WWW is counted in months (not years) that’s a #fail.”

@algermissen – “REST frameworks that hide too many HTTP details tend to really get in your way in the long run :-(”

@mamund – “#hypermedia challenge: what if you were not allowed to put any URIs in your client code? could you still write a fully-functional app?”

@dret – “mapping server-side #XML directly to URIs leads to (a) excessive granularity, (b) namespace problems, (c) API instability, and (d) insanity.”

@dret – “or more generally speaking: link relationship types should not make any assumptions about the media types on both ends of the link.”

@dret – “another link relationship registry question: wouldn’t it be very useful to know when two relationship types are the inverse of each other?”

@darrel_miller – “Different media types are like different vehicles on the road. Use the right one for for the right job.”

@dret – “apart from priority, in-representation links, protocol-level links, and external link overlays should all be treated equally. #REST”

@mikekelly85 – “Fellow devs; please stop creating custom media types for your web APIs. You don’t extend HTML to build a web app, why do it with an API?”

@mamund – “creating stand-alone app requires mapping problem domain to src code. creating WWW app requires mapping problem domain to msgs. #Hypermedia”

@joehewitt – “Maybe the biggest threat to the web is JSON APIs, the lingua franca of native apps, which offer no hyperlinking and no standard semantics.”

@mikekelly85 – “Atom(pub) failed because it forces you to model resources as collections & items, instead of other way round i.e. cols/items as resources”

This Week in #REST – Volume 40 (Sept 12 2011 – Nov 16 2011)

This is Volume 40 of This week in REST, for September 12 2011 – November 16 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

Web API Design Cookbook – “This document captures common practices in designing APIs that fit well into the Web platform as a whole, using WebIDL”

What the Web is and is not – “I’m beginning to see that some parts of the Web we take for granted are not what actually defines it. The Web is not HTML, CSS, and JavaScript. It’s not DOM, SVG, WebGL, PNG, or Flash. The Web is really just HTTP over TCP/IP. What gets transported over HTTP does not define the Web.There is, however, one other characteristic that does define the Web, and that is the humble hyperlink. Links are a feature of HTML, but they are not limited to HTML. Links are the connections that give the Web its name, and links are the biggest thing missing from native platforms.” (by Joe Hewitt)

The web interface should be radically refactored – “The Web API conflates two conflicting goals: serving developers by supporting a wide and growing suite of functionality, and providing applications with an isolated execution environment. We propose to split the API into two levels of interface: a low-level interface that governs the relationship between the application and the browser, and a set of high-level interfaces that govern the relationship between the application and its developer. We delineate a tiny set of properties needed by the low-level interface. We argue that this restructuring provides significant benefit to both developers and users.” (by Jon Howell, John Douceur, Bryan Parno)

hypermedia affordances – “right now i am of the opinion that a single set of aspects of hypermedia affordances can be identified. that this set would be universal to all hypermedia designs; no matter the protocol used (HTTP, FTP, etc.), the data format used (HTML, JSON, etc.). and that set of aspectsshould be enough to “construct” any hypermedia control needed in order to support a particular action in a distributed application.” (by Mike Amundsen)

Prefer Header for HTTP – “This specification defines an HTTP header that can be used by a user-   agent to request that certain behaviors be implemented by a server   while processing a request.” (IETF draft by J. Snell)

Using Hypermedia Services for Systems Integration – (presentation) “Tim Ewald explains why hypermedia is good for system integration through services –providing support for evolution, service request routing, and application recovery-, and how to build such services. ” (by Tim Ewald)

Cool URIs and Integration – “A key design aspect that made the very success of the World Wide Web possible was the removal of the referential integrity constraint from the hypermedia paradigm. In a system of the scale of the Web the problem of ensuring that no hyperlink would ever be broken cannot be solved and the only way to make the system work was to relax the constraint.” (by Jan Algermissen)

Creating Resources with GET/PUT – “creating resources the RESTful way can be done with either PUT or POST, with PUT expecting that the URI of the created resource is known in advance (by the client issuing the request). semantically, the difference is that PUT is idempotent and thus can be repeated safely, whereas POST is non-idempotent and thus cannot be repeated. a PUT can be repeated because after creating a resource, a repeated PUT will simply overwrite the resource with the same representation, whereas a POST always is directed towards some factory resource, and thus repeating it would create a duplicate, which should be avoided.in many cases, clients do not know the URI of the new resource, so the PUT approach cannot be used. the problem with the simple POST model is that clients have a hard time figuring out what to do when the POST request fails (e.g., the HTTP library says something went wrong).” (by Erik Wilde)

TAG f2f04 Nov 2011 – Minutes from the W3C TAG face-to-face meeting in November.

RESTful Web Service Discoverability, part 4 – “Discoverability of an API is a topic that doesn’t get enough well deserved attention, and as a consequence very few APIs get it right. It is also something that, if done right, can make the API not only RESTful and usable but also elegant.To understand discoverability, one needs to understand that constraint that is Hypermedia As The Engine Of Application State (HATEOAS); this constraint of a RESTful API is about full discoverability of actions/transitions on a Resource from Hypermedia (Hypertext really), as the only driver of application state. If interaction is to be driven by the API through the conversation itself, concretely via Hypertext, then there can be no documentation, as that would coerce the client to make assumptions that are in fact outside of the context of the API.”

Web API Versioning Smackdown – “The answer is that there is no one answer; there are lots of different mechanisms in HTTP to meet the goals that people have for versioning.However, there is an underlying principle to almost any kind of of versioning on the Web; not breaking existing clients.The reasoning is simple; once you publish a Web API, people are going to start writing software that relies upon it, and every time you introduce a change, you introduce the potential to break them. That means that changes have to happen in predictable and well-understood ways.” (by Mark Nottingham)

URI construction: give it a REST – “Picture the scene: you’ve just updated your product’s REST API. You’ve added lots of new features, revamped the URI structure and you’re excited for your clients to start using it.One of these two things will happen within the hour:Your support line will ring off the hook with angry customers screaming about how none of their applications are working anymore, and how they’re going to wring your neck for breaking their systems at the worst possible time.Everything works great and your customers send you chocolates in gratitude for the new features.The problems in #1 will occur if your customers do any kind of URI construction in their REST API client applications. That innocuous “revamping” of your URI structure has just broken all the clients who were tightly bound to the exact format and layout of your old URIs.” (by Brian Kelly)

Webmachine: a Practical Executable Model of HTTP – (presentation) “Justin Sheehy details Webmachine, a RESTful toolkit for writing well-behaved HTTP applications, helping developers to deal with the complexities of an HTTP-based application. ” (by Justin Sheehy)

APIs are for human beings (too) – “Computers don’t care about API design. Convenient serialization formats, sane parameter names, and a RESTful interface mean nothing to a robot.  These aspects of an API are not meant for a machine, they’re meant for you – the developer.  APIs should be for human beings first and computers second.” (by Frank Stratton)

How REST replaced SOAP on the Web: What it means to you – ” The idea of reuse and composition made SOA an attractive proposition that sent thousands of organizations on a very challenging treasure hunt. We have since read SOA’s obituary and its resurrection with many stories of woe peppered with some success, but with very few achieving the holy grail of SOA. Meanwhile, the web has essentially become a service oriented platform, where information and functionality is a available through an API; the Web succeeded where the enterprise largely failed.This success can be attributed to the fact that the web has been decentralized in its approach and has adopted less stringent technologies to become service oriented.” (by Ross Mason)

I Hate HatEoAS – “For something that’s supposed to be THE defining characteristic of REST, it could have done with better naming. I would have been happy with the term HatEoAS if it had stood for “Hypermedia as the Envelope of Application State” rather than “Hypermedia as the Engine of Application State”. (by Ganesh Prasad)

hypermedia binding – “a solution to the evolving-over-time problem for dist-net apps is to bind clients and servers via a shared understanding of hypermedia controls. IOW, change the binding from first-class domain elements to an abstract expression of those elements; to elements (links and forms) that make “animating” dist-net apps possible.” (by Mike Amundsen)

Discussion groups

Which URIs are bookmarkable? – Very interesting thread on the “theory” behind bookmarking links. “In general, I am trying to answer the question:What are the indicators in media type (and link relation) specifications that tell the user agent implementor what URIs in responses of the media type in question can be considered bookmarkable?”

Reviews of draft-freed-media-type-regs-01 needed – Roy’s thoughts on media type registration process. “We should be *encouraging* vendors to ship with vendor-neutral short-namedtypes regardless of whether they have been registered yet or not, and thenwe should be *encouraging* the public to register any names that they haveseen in deployed software.”

Using URI templates in XHTML– Interesting thread on URI templates and hypermedia controls. “I’d like to use URI template as hypermedia control in XHTML, as a (richer) alternative to my existing forms. What do you think is the best way to do so ? Specifically, how would you represent an URI template in XHTML (given it must be used as a hypermedia control for programatic clients)?”

absolute or relative URLs in links? – “Is there a consensus?An absolute URL is, I guess, easier to consume by a client, whereas a relative link is also going to need some sort of (equivalent to HTML)BASE tag so that the client can build the URL to hit.”

Denormalizing Data In To Collection Resources? – “Is there any good research trading off the chattiness, cachability,latency and redundancy of denormalized data in RESTful collection resources? Are there good rules of thumb to apply here. It’s temptingto say do the N hundred HTTP requests and come back when you can showit’s a problem, but that doesn’t go down well…”

Events

W3C Workshop on Data and Services Integration – Papers from the W3C workshop held on October 20-21 2011 in Bedford, MA, USA.

Interesting tweets

@mikekelly85 – “HTTP error responses aren’t reps of a resource’s state, they’re reps of a failure state produced by an intermediary mechanism”

@dret – “search is not a function or a property of a single resource, it’s a capability available for a collection & may be independent of it. #REST”

@AndrewWahbe – “Think of a hypermedia type as a client-defined interface that services can implement to plug into the client”

@mamund – “RT @dret: “once you hit a resource where the representation signals success, that test has been successful.” express as assert, right? #REST”

@kidehen – “Data is the New Electricity with Hyperlinks (#URIs) as the conduction mechanism :-) #LinkedData #GartnerSym”

@mamund – “media types can be used to express shared understanding of problem domain(s) in an implementation-agnostic format. #HTTP #REST #Hypermedia”

@distobj – “Pro tip; when writing HTTP/JSON apps, throw in a crude-but-complete HTML repr to keep you honest wrt hypermedia #REST”

@dret – “any non-trivial testing of #REST services needs “random link exploration” and some domain knowledge of “test space boundaries.” what else?”

@mamund – “RT @amirrajan: “still question the need for “restful” uris when you have hypermedia” i agree: startingURI(s)+HM = minimal URI rules (cont)”

@dret – “@mamund goal-driven state machine based clients doing some validation and aggregation along the way. it’s a huge research opportunity!”

@dret – “there’s #HTTP, there’s #WebDAV on top, and now there’s #CalDAV and #CardDAV. do we really need a specific protocol for each application?”

This Week in #REST – Volume 39 (Aug 11 2011 – Sept 22 2011)

This is Volume 39 of This week in REST, for August 11 2011 – September 22 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

InfoQ Explores: REST – “This is the first edition of what is expected to become a recurring series on InfoQ. The idea behind this minibook is that a number of InfoQ articles and interviews which deal with a particular topic (in this case, REpresentational State Transfer, or REST) are combined together to provide a detailed exploration suitable for both beginners and advanced practitioners.”

Restful turing machines – “I went to bed a couple of hours ago but every time I started to drift off a mosquito buzzed by. Led to this train of thought – how would you build a Universal Turing Machine with hypertext as the engine of state?” (by Danny Ayers)

Clarifying REST – “The definition of REST lost its way when popular services emerged calling themselves REST which were not. An API like Twitter is ignoring the values of the web and the browser by using HTTP as a transport for RPC (Remote Procedure Call). SOAP services also use HTTP in this way. Instead of doing RPC, HTTP should be used to transfer application state which is what REST is designed for.” (by Kelly Sommers)

Web Oriented Architecture is here to Stay, and Why Microsoft’s new WCF Stack is interesting – “WCF vNext Web Apis is a promising offering from Microsoft, but the key is evolving curry frameworks and tooling on top of the new Web APIs to support address common WOA concerns. WOA is more or less a set of best practices than a well defined methodology, so I’m not sure to what extent this can be abstracted.” (by Anoop Madhusudanan)

Identifying 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 W3C TAG)

Getting Things Done with REST – (video) “Ian Robinson discusses how to implement a hypermedia-driven web application and how to test its workflow giving as example a RESTful web service he built on top of Microsoft’s Web API. ” (by Ian Robinson)

Better Browser Caching – “In discussing my whinge about AppCache offline with a few browser vendory folks, I ending up writing down my longstanding wishlist for making browser caches better. Without further ado, a bunch of blue-sky ideas;” (by Mark Nottingham)

Three levels of abstraction – “i’ve spent the last year or so focusing on identifying the relationship between the protocol abstraction and the message abstraction. i’ve done this by analyzing various existing media types; developing a set of H-Factors common to all message formats that want to express protocol-level features via hypermedia controls.the next logical step is to analyze existing hypermedia implementations to locate and identify the general principles for expressing domain information within a hypermedia message. ” (by Mike Amundsen)

URI Template – (new version of IETF draft) “A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet.”

When Acronyms Collide: SOA vs. OO – “This article looks at a particular aspect of the current state of enterprise IT: the entangled relationship between the mindset and practices of large-scale Object Oriented application development, and the requirements of Service Oriented Architecture. This relationship has gone wrong and will remain a problem – a costly problem – until it’s put right.” (by Bill Blondeau)

Discussion groups

REST API For Documentation? – “While thinking about documentation for the API we’re working on one ofour team suggested building a REST API to document the REST API. Resources in the documentation API would correspond to media types and contain data on the methods and properties available in those media types. Has anyone seen this done before? How did it work out?”

Conneg based on User-Agent – “human targeted Web sites somtimes (or usually?) adjust the representations they send based on their knowledge about the abilities of the user agents (e.g. IE might get different stuff than FireFox).I think using the UserAgent header to negotiate representation features is a nice solution for non-human targeted situations, too. ”

Are URI-Templates really coupling clients and server? – “In different resources on the web, i found different opinions about URI Templating. Some say, they are coupling clients and server (e.g. Erik Wilde). Some propose their usage (e.g. subbu).I dont see any coupling – it is not said, that an URI Template connot changed either over time. As long as the server communicates the templates – like URIs – in resource representations, where is the problem?”

Events

RESTfest 2011 – if you missed this year’s RESTfest, watch the videos on-line here.

ECOWS 2011 – check out the many interesting papers from this year’s European conference on web service and the co-located workshops.

Interesting tweets

@mamund – “RT @dret: @algermissen “i don’t think app-specific protocols are good way to go.” options: 1)protocol, 2)media-type, 3)URI. i pick 2) #REST“

@dret – “@mamund i prefer to think of it as design patterns of solving common problems with (maybe new) media types and existing methods. #REST“

@dret – “@mamund wrt #WebDAV and #CalDAV: they invent new methods, which are not really something you can easily do by just adding new types. #REST“

This Week in #REST – Volume 38 (Jun 28 2011 – Aug 11 2011)

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“

This Week in #REST – Volume 37 (Jun 1 2011 – Jun 27 2011)

This is Volume 37 of This week in REST, for June 1 2011 – June 27 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

designing a RESTBucks media-type – “for this blog post, i’ve commandeered the RESTBucks examples from REST in Practice in order to illustrate a simple methodology for expressing application domain details as hypermedia types in a way that works for HTTP and the Web. keep in mind this is my own interpretation of the RESTbucks example and is not meant to indicate the endorsement or approval of the authors of REST in Practice.the material that follows is based on content from a new book i am working on entitled “Building Hypermedia APIs with HTML5 and Node” that will be released later this year.” (by Mike Amundsen)

W3C TAG meeting 6-8 June 2011 in Cambridge, MA, USA – Agenda and minutes from the latest W3C TAG meeting + comments from Jeni Tennison.

HttpRange14Webography – A chronology of discussions about the HTTP range-14 issue.

Media Type Specifications and Registration Procedures – “This document defines procedures for the specification and   registration of media types for use in MIME and other Internet   protocols.” (IETF draft – N. Freed, J. Klensin, T. Hansen)

HAL – Hypertext Application Language: A lean hypermedia type for RESTful APIs – “HAL is a simple, generic hypermedia type based on JSON and XML for use in RESTful APIs. Essentially, HAL provides a set of conventions for expressing hyperlinks to, and embeddedness of, related resources – the rest of a HAL representation is just plain old JSON or XML. HAL consists of two reserved elements: Resource and Link. Any and all elements are legal in a HAL representation provided they do not conflict with HAL’s reserved elements.” (by Mike Kelly) + a comments thread on the REST mailing list

We live in a POST REST/SOAP World – “we now live in a POST REST/SOAP world. Converged (Mobile) Applications have pushed the envelope of what distributed computing should do and how it does it. Never HTTP or SOAP were really prepared for 3-legged authentication, respect privacy and support monetization at the scale of several billion API calls/month. Actually SOAP was a bit more prepared since a message could have a number of security tokens representing different principals, but who cares, we were told that HTTP was the answer, because it was “RESTful” so now we struggle with all kinds of three-legged authentication mechanisms.” (by Jean-Jacques Dubray)

designing a RESTBucks media-type – (by Mike Amundsen)

How Offline Web Apps Should Work – “The essence of this proposal is that a proper solution to the offline web app problem should not require drawing a distinction between “offline” and “online” assets. There is no need for ‘cache manifests’, or to create a separate ‘application cache’ from the standard browser cache.This solution should leverage existing web caching infrastructure (i.e. HTTP headers such as Cache-Control, Etags, etc) to control how browsers store and negotiate the assets required to run the application offline.” (by Mike Kelly)

The trouble with APIs – “1. REST APIs are a case of good intentions run amok. The point of REST was to *eliminate* specific APIs. Not cause their proliferation. 2. When someone says you shouldn’t document a REST API, they’re saying you shouldn’t have an API. Not that you shouldn’t document. 3. That said, RESTians saying you shouldn’t have an API are somewhat vacuous because they offer no good alternative. Custom media types ain’t. 4. Thus, IMO, until we have a workable generic media type or two for the 80% case of “REST APIs”, we’re just growing a frustrating mess.” (by Stuart Charlton)

The Good, the Bad, and the Ugly of REST APIs – “Adrian Cole of jclouds and I have written a lot of code against a variety of SOAP and REST cloud computing APIs. We’ve seen a lot of the good, the bad, and the ugly in API design and we tend to complain to each other about the things we dislike. This article sums up my thinking on the subject (not necessarily Adrian’s, though Adrian reviewed the document and gave me additional ideas).” (by George Reese) + a comment post from William Vambenepe.

Providing and discovering definitions of URIs – “A few widely known methods are in use to help agents provide and discover URI definitions, including RDF fragment identifier resolution and the HTTP 303 redirect. Difficulties in using these methods have led to a search for new methods that are easier to deploy, and perform better, than the established ones. However, some of the proposed methods introduce new problems, such as incompatible changes to the way metadata is written. This report brings together in one place information on current and proposed practices, with analysis of benefits and shortcomings of each.The purpose of this report is not to make recommendations but rather to initiate a discussion that might lead to consensus on the use of current and/or new methods.” (by Jonathan Rees)

What REST needs to do to succeed in the enterprise – “In the spirit of constructive criticism here is what REST needs to do in order to succeed in the enterprise and B2B markets, the sort of markets that make actual revenues and profits as opposed to hype markets with the stability of a bubble. First off there is the mental change required, four steps here. Focus on how people and especially teams work. Accept that HTTP isn’t a functional API. Accept that enterprise integration, B2B and Machine to Machine require a new approach. Accept that the integration technology isn’t the thing that delivers value.” (by Steve Jones)

REST isn’t undead in the enterprise… its still born – “All this just proves what I’ve said for a long time. REST works for information traversal, but its not set up for the enterprise. So what is the issue with REST not displacing SOAP in the enterprise? …. REST needs a standard way to publish its API and for a way to notify changes in that API. This is a “solved” problem in IT but for some reason the REST community appears to prefer blaming others for the lack of enterprise success of their technology rather than facing up to the simple reality…” (by Steve Jones)

All About EVE: Extensibility, Versioning, Evolvabiility, etc. through Modifiability – Excellent presentation slides on versioning and evolvability in (RESTful hypermedia) systems. (by Mike Amundsen)

REST mailing list

Definition of a Hypermedia Client – excellent attempts at defining a hypermedia client.

Stateful APIs – “Consider a simple photo storage service as an API. Users can only interactwith the API if they’ve got an account. Let’s say authorization happensoverHTTP Basic. Given that, would you use URIs like /photos and /photos/{id} (as a photo listand photo detail resource, respectively)? What’s weird about those URIs isthat my /photos is a different list of photos than your /photos — in otherwords, the resource represented depends on the information intheAuthorization header.”

Events

ICWE2011 – The 11th International conference on Web engineering was held at Paphos, Cyprus. Check out the program page for the list of presented papers and the workshops page for the list of workshops. I didn’t go through the papers from all the workshops yet, but at lest 2-3 papers from the main conference should be interesting in the context of REST:

• Irum Rauf and Ivan Porres. Validating Behavioral RESTful Interfaces using Semantic Web Technologies
• Kamara Benjamin, Gregor Bochmann, Mustafa Emre Dincturk, Guy-Vincent Jourdan and Iosif Viorel Onut. A Strategy for Efficient Crawling of Rich Internet Applications
• Ivan Zuzak, Ivan Budiselic and Goran Delac. Formal Modeling of RESTful Systems Using Finite-State Machines (draft of full paper is here, presentation slides are here)

The proceedings of the conference are published by Springer, but I’m sure that Googling for paper titles will also go a long way.

Interesting tweets

@svrc – “REST APIs are a case of good intentions run amok. The point of REST was to *eliminate* specific APIs. Not cause their proliferation.”

@sallamar – “What the discussions about failure/success of REST are missing – (a) that REST is NOT prescriptive and so don’t try to make it prescriptive”

@svrc – “When someone says you shouldn’t document a REST API, they’re saying you shouldn’t have an API. Not that you shouldn’t document.”

@pkeane – “theory: value (+ maybe RESTfulness) of an API can be measured by how easily I can open a representation in a text editor & make sense of it”