{"id":331,"date":"2004-04-16T11:16:00","date_gmt":"2004-04-16T15:16:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/?p=342"},"modified":"2004-04-16T11:16:00","modified_gmt":"2004-04-16T15:16:00","slug":"baby-steps-on-the-road-to-web-nirvana","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2004\/04\/baby-steps-on-the-road-to-web-nirvana\/","title":{"rendered":"Baby steps on the road to Web nirvana"},"content":{"rendered":"<p>So apparently <a href=\"http:\/\/www.markbaker.ca\/2002\/09\/Blog\/2004\/04\/10#2004-04-webber-ambushed\">&#8220;processThis&#8221;<\/a>\nis now &#8211; get this &#8211; an\n<a href=\"http:\/\/jim.webber.name\/#150420040057\"><em>imaginary<\/em><\/a> method. 8-)<\/p>\n\n<p>But I know exactly what Jim&#8217;s talking about.  I just wouldn&#8217;t use the word &#8220;imaginary&#8221;,\nbecause it&#8217;s definitely there, aka &#8220;in effect&#8221;, it&#8217;s just implicit; consider that a fault\nwould mean &#8220;Sorry, there was a problem processing this&#8221;.  It&#8217;s exactly like streaming\nvideo; video data arrives, it gets processed, moving pictures result.  What we&#8217;re really\ntalking about here (and I just noticed he had some\n<a href=\"http:\/\/jim.webber.name\/2004\/04\/16\/2bcf290a-9162-497d-8b50-3827c7907802.aspx\">more to say on the subject<\/a>,\nin his brand .. new .. weblog! 8-) is the difference between these two types of messages;<\/p>\n\n<pre>\nHello there\n<\/pre>\n\n<p>and<\/p>\n\n<pre>\nPOST some-identifier HTTP\/1.0\nContent-Type: text\/plain\n[blank line]\nHello there\n<\/pre>\n\n<p>In order to make both messages semantically identical though, some additional\nwork is required.  First, the message has to arrive through a channel which has\nassociated with it &#8220;processThis&#8221; semantics; you can&#8217;t just send it along on\nport 25 (the SMTP port) as is, and expect anybody to understand that you\nwant them to process that data.  So you really need a new port, which you have to\n<a href=\"http:\/\/www.iana.org\/assignments\/port-numbers\">obtain through IANA<\/a>.\nTo do that, you&#8217;ll need to describe to the <a href=\"http:\/\/www.iesg.org\">IESG<\/a>\nwhat the semantics of that port are, which you do by publishing an RFC which describes\nwhat &#8220;processThis&#8221; semantics are, and states that any data arriving on your special\nport will have those semantics.  You&#8217;ll also need to state which spec controls the\ninterpretation of the data, as there&#8217;s no (in my example, anyhow) way to indicate\nthat as part of the message, ala the role that Content-Type plays in the HTTP\nmessage.  Phew!  That&#8217;s a whole lot of semantics to attach to a single port number!<\/p>\n\n<p>Which brings me to the advantages of doing all that stuff as part of the\nmessage.  First, it&#8217;s far more extensible.  With the former example, if either\nthe semantics of the interaction, or the semantics of the data processing need\nto change.  For example, what if you want to query or store data, rather than\njust having it processed?  You&#8217;re SOL.<\/p>\n\n<p>Practically all large scale systems nowadays make their semantics explicit\non-the-wire rather than implicit, in large part for reasons such as those I\ngave.  Even some AV streaming protocols like <a href=\"http:\/\/www.rtsp.org\/\">RTSP<\/a>\ndo too.<\/p>\n\n<p>But my intent here isn&#8217;t to critique this approach.  The extensibility\nproblem is a relatively minor problem compared to the enormous win of using a\nuniform semantic.  What I&#8217;m really doing here is trying to describe how REST\nand Web architecture are an <em>extension<\/em> on top of this simple but powerful\nform of interaction.  Or in other words, you could build a large scale system\nwith the approach that Jim and Savas advocate, and it would be hugely wonderful\nthing.  But it would still just be a subset of the Web in terms of size and\nfunctionality.  Let me ask a couple of leading questions that might help drive\nhome that point &#8230;<\/p>\n\n<p>First, how do you address your messages?  Just to a remote IP\/port?\nI think you&#8217;d agree that you&#8217;d need a standard way to address remote data\nprocessors, no?  And that address would have to be part of the message,\notherwise you&#8217;re stuck with a single processor per IP\/port tuple.  So now,\nyou&#8217;ve got a means of identifying anything which can reasonably be modelled\nas something that accepts data.  For example, you could have an identifier for\nme, and if you sent your data to my identifier, perhaps the content would\nappear on my Blackberry, or arrive on my fax machine or some-such.  It would\nbe very much like email.<\/p>\n\n<p>So now, you have these wonderful standardized identifiers, which you know\nidentify things, many of which have some state associated with them (like myself 8-).\nWouldn&#8217;t it be useful to have a uniform means of requesting that state be\nserialized as a response message?  That&#8217;s the role that GET plays in Web\narchitecture.  And the URI is, of course, the standardized identifier.<\/p>\n\n<p>Can you see why I&#8217;m so excited?  You (Jim) and Savas are so far ahead of the\nWeb services crowd, that you&#8217;re actually describing something that&#8217;s as useful as\nemail (I&#8217;m not being facetious, that&#8217;s really a wonderful thing)!  But the Web is\njust a baby step away.<\/p>","protected":false},"excerpt":{"rendered":"So apparently &#8220;processThis&#8221; is now &#8211; get this &#8211; an imaginary method. 8-) But I know exactly what Jim&#8217;s talking about. I just wouldn&#8217;t use the word &#8220;imaginary&#8221;, because it&#8217;s definitely there, aka &#8220;in effect&#8221;, it&#8217;s just implicit; consider that a fault would mean &#8220;Sorry, there was a problem processing this&#8221;. It&#8217;s exactly like streaming [&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-331","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/331","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=331"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/331\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=331"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=331"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=331"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}