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)
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)
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)
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)
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.”
#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.
@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.
@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.”
#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”.
@dret: “you don’t need a link relation type for each interaction type. HTTP methods and/or transferred state can allow multiple interactions.
@dret: “in RDF, URIs are opaque identifiers with no semantics; in REST, they are handles for interactions and encode those semantics.”