{"id":102,"date":"2003-03-09T19:54:00","date_gmt":"2003-03-09T23:54:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/?p=211"},"modified":"2003-03-09T19:54:00","modified_gmt":"2003-03-09T23:54:00","slug":"clemens-vasters-ponders-rest","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2003\/03\/clemens-vasters-ponders-rest\/","title":{"rendered":"Clemens Vasters ponders REST"},"content":{"rendered":"<p>Clemens\n<a href=\"http:\/\/radio.weblogs.com\/0108971\/2003\/03\/09.html#a127\">has some doubts and questions<\/a>\nabout REST, which I&#8217;m more than happy to respond to.<\/p>\n\n<blockquote>\nWhat I don&#8217;t get together is the basic idea that &#8220;every thing is a uniquely identifiable resource&#8221; with the bare fact that the seemingly limitless scalability of the largest websites is indeed an illusion created by folks like those at Akamai, which take replicated content around the globe and bring it as close as possible to the clients\n<\/blockquote>\n\n<p>I&#8217;ve heard this objection several times.  What I always point out, is that REST\nis explicitly\n<a href=\"http:\/\/www.ics.uci.edu\/~fielding\/pubs\/dissertation\/rest_arch_style.htm#sec_5_1_6\">layered<\/a>,\nand that the Web is scalable <em>because<\/em> Akamai and other solutions like it, can exist.<\/p>\n\n<blockquote>\nTaken to the last consequence of every data facet being uniquely identifiable through a URI (which it then should be and is) this model can&#8217;t properly deal with any modification concurrency.\n<\/blockquote>\n\n<p>Not true.  There are many known means of dealing with concurrent\naccess to data, and the Web has a good one; see the\n<a href=\"http:\/\/www.w3.org\/1999\/04\/Editing\/\">lost update problem<\/a>\n(though other solutions may be used too).  The one described in that\ndocument is actually a very well designed one too, as other solutions\nhave problems with &#8220;hand of god&#8221; centralization issues (e.g. round\nidentifiers).<\/p>\n\n<p>While this solution only addresses concurrent access to an individual\nresource, <a href=\"http:\/\/www.ietf.org\/rfc\/rfc2518.txt\">WebDAV<\/a> offers some\nuseful extensions for dealing with collections of resources, and concurrent\naccess to them.<\/p>\n\n<blockquote>\nSo, what are the limits of data granularity to which REST applies?  How do you define boundaries of data sets in a way that concurrency could work in some way [&#8230;]\n<\/blockquote>\n\n<p>REST&#8217;s level of data granularity is the resource, but a resource\ncan be a collection of other resources, as WebDAV recognizes.<\/p>\n\n<blockquote>\nand how do you define the relationship between the data and the URI that identifies it?\n<\/blockquote>\n\n<p>By use; the data returned by GET over time determines what the URI identifies.\nThough in the case a resource that&#8217;s created by PUT, then the one who&#8217;s doing the\nPUTting already knows, since they&#8217;re directly effecting what GET returns.<\/p>\n\n<p>So to sum up, I too believe that REST has places where it&#8217;s useful, and places\nwhere it&#8217;s not, and that there will be other useful systems deployed on the\nInternet which are not built around REST or REST extensions.  But I don&#8217;t believe\n&#8220;Web services&#8221; will be amoungst them, because the current approach fails to recognize\nthat <a href=\"http:\/\/www.oreillynet.com\/cs\/weblog\/view\/wlg\/1681\">being built around\na coordination language is essential to any Internet scale system<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"Clemens has some doubts and questions about REST, which I&#8217;m more than happy to respond to. What I don&#8217;t get together is the basic idea that &#8220;every thing is a uniquely identifiable resource&#8221; with the bare fact that the seemingly limitless scalability of the largest websites is indeed an illusion created by folks like those [&hellip;]","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-102","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/comments?post=102"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/102\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=102"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}