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)
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.”
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.
@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.”
@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 – “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)”