{"id":325,"date":"2004-04-10T01:41:00","date_gmt":"2004-04-10T05:41:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/?p=348"},"modified":"2004-04-10T01:41:00","modified_gmt":"2004-04-10T05:41:00","slug":"jim-webber-ambushed-by-rest-advocates","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2004\/04\/jim-webber-ambushed-by-rest-advocates\/","title":{"rendered":"Jim Webber ambushed by REST advocates"},"content":{"rendered":"<p>Now, <em><a href=\"http:\/\/jim.webber.name\/#080420041140\">that&#8217;s<\/a><\/em> cute.<\/p>\n\n<p>I&#8217;ll get right to the point.  He writes;<\/p>\n\n<blockquote>\nHowever, in the asynchronous case, imagine your Web Service is just like a letterbox. Letters happily fit into the letterbox and get processed by the back-end (i.e. you), but the 42&#8243; plasma screen TV you ordered doesn&#8217;t fit into the letterbox &#8211; it doesn&#8217;t match the physical dimensions (as per its &#8220;schema&#8221;). This seems RESTful, no?\n<\/blockquote>\n\n<p>Absolutely.<\/p>\n\n<blockquote>\nThe fact is that regular Web Services have a far more uniform interface than the REST style. I&#8217;ve laid down the challenge before, but you can&#8217;t get much more uniform than one (imaginary) verb, can you?\n<\/blockquote>\n\n<p>That&#8217;s really good to hear you say that Web services have uniform semantics.  But\nit&#8217;s impossible for them to be <em>more<\/em> uniform than REST, because REST\nprescribes uniform interface semantics by definition.\nThat verb you talk about &#8211; &#8220;processThis&#8221; &#8211; if it is indeed uniform,\nthen it has semantics that are, for the purposes of this discussion, identical to\nHTTP POST.  And you <em>can<\/em> build a perfectly RESTful system with just that one\nverb, and it would be accurately characterized as loosely coupled and based on document\nexchange.  In fact, I just built one a couple of weeks ago like that for pumping three\nchannels of seismographic data from a digitizer to a communications controller.  It&#8217;s just\nthat in my experience, for most applications, you can build a better RESTful system with\nadditional verbs, in particular GET.  For example, if there were any need to have my\ncomms controller initiate the request for data, I&#8217;d use GET.<\/p>\n\n<p>The other approach to requesting data is to, for example, submitting documents which\ndescribe query terms or templates to services which process them and return the\nresults.  And that also has its place in RESTful systems, including ones I&#8217;ve\ndeveloped.  But when you don&#8217;t have to query, e.g. when the endpoint identifier for\nthe service\/resource to which you POST that document identifies something stateful,\nthen GET is perfect for retrieving that state (such as the aforementioned seismic\ndata).  And of course, URIs makes the perfect endpoint identifier because they&#8217;re\neasily identified and contain all the information you need to grab the data (at least\nthe good ones do 8-), without needing to know how to do a query on them.<\/p>\n\n<p>Anyhow, this discussion is super-duper encouraging from my POV.  We&#8217;ve come a long\nway from early Web Services Architecture WG meetings where folks were claiming things\nlike &#8220;GET, PUT, and POST are only good for browsers&#8221;, or &#8220;REST requires humans&#8221;.\nA long way, indeed.<\/p>","protected":false},"excerpt":{"rendered":"Now, that&#8217;s cute. I&#8217;ll get right to the point. He writes; However, in the asynchronous case, imagine your Web Service is just like a letterbox. Letters happily fit into the letterbox and get processed by the back-end (i.e. you), but the 42&#8243; plasma screen TV you ordered doesn&#8217;t fit into the letterbox &#8211; it doesn&#8217;t [&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-325","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/325","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=325"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/325\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=325"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=325"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=325"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}