{"id":96,"date":"2003-02-16T21:57:00","date_gmt":"2003-02-17T01:57:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/?p=217"},"modified":"2003-02-16T21:57:00","modified_gmt":"2003-02-17T01:57:00","slug":"discussion-on-jorgens-presentation","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2003\/02\/discussion-on-jorgens-presentation\/","title":{"rendered":"Discussion on Jorgen’s presentation"},"content":{"rendered":"

Jorgen responds<\/a>\nto my comments<\/a> on a\npresentation<\/a>\nhe gave last week.<\/p>\n\n

Re my comment that architectural styles are pattern languages, not patterns,\nI can only point to Roy’s dissertation on this, where he suggests the association\nbetween an Alexendar “pattern language” and an “architectural style”, by suggesting\nindirectly that both are a system of patterns that constrain the form of the resultant\nsystem. “Stateless”, “Uniform interface”, “Layered Client Server”, etc.. are\nconstraints, and when coordinated together, form the REST architectural style.<\/p>\n\n

Re the stateful\/stateless point (both parts), I don’t see how whether the targetted\nendpoint does additional dispatch or not, matters to this issue, unless of course that\ndispatch operation uses some state (which is not required of an OO style, AFAICT).\nYou suggest that all object oriented styles are stateful, yet REST is stateless, and\nit’s object oriented in that messages are targetted at identifiable objects.<\/p>\n\n

Re SQL, and to add to my last blog, it’s true that a SQL row may be a\nresource, but it’s not the case that all resources (as defined in 2396)\ncan be manipulated via SQL.<\/p>\n\n

Re POST, perhaps we miscommunicated, but by “partial update” I thought you\nmeant that the meaning of POST permitted the updating of partial state\nchanges to be communicated to the client<\/em>, which it doesn’t. It is\ntrue that the effect of a POST may be a “partial update” of the state of the\nresource, but the issue is that a client will not know that. All a successful\nresponse to a POST can mean to a client is “thanks, I accept this data”.\nSo I’d say that your comparison to SQL UPDATE is inaccurate, because after a\nsuccessful UPDATE, the client knows the state of some part of some table.\nUPDATE is more like PUT for this reason, whose successful invocation informs\nthat client that the state of the resource is what they asked for it to be.<\/p>\n\n

Jorgen writes;<\/p>\n\n

\nAnd there I was thinking this statement would be an olive branch for you, Mark ;-)\n<\/blockquote>\n\n

Heh, yah, I appreciated the attempt, but I felt it was pretty early to propose\na synergy existed before you really understood REST. Oh, and please don’t take\nthat<\/em> the wrong way 8-); understanding REST isn’t a matter of smarts, it’s\njust a matter of recognizing what it is (or more specifically, what an application\nprotocol is, at least in my experience as an ex-CORBA lover). I’m confident that\nyou’ll understand soon enough because of your broad experience, and your eagerness\nto learn.<\/p>\n\n

\nI still don’t see any real conflict – you can still have requests returning XML data, the only question would be whether the request data must be in XML format or whether it can be encoded into a URL\/URI.\n<\/blockquote>\n\n

Depends what you mean by “request data”. A typical Web services centric solution,\nbecause its normally early bound, requires that the request data include a\nmethod name. REST, because it’s late bound, requires only that you provide\nan identifier. From a cost-of-coordination perspective, the latter is\nvastly superior.<\/p>\n\n

\nYou can use Web Services standards and do pure REST.\nEqually you can use Web Services standards and _not_ do REST.\n<\/blockquote>\n\n

Of course. As I said before, I consider this a bug, not a feature.<\/p>\n\n

Roy defined the\nnull architectural style<\/a>\nwhich could be said to be another style in which you can do REST\nor not. The way it does this is by being entirely devoid of constraints,\nwhich has the “disadvantage” (cough 8-) of also being entirely devoid of any\ndesirable properties.<\/p>\n\n

I’m not suggesting that you believe that the null style is a useful thing,\nbut I’ve heard from a lot of Web services folks who feel that architectural\nconstraints are a bad<\/em> thing. From a software architecture point of\nview, this is madness. Have they never heard of entropy? 8-\/<\/p>\n\n

\nFundamentally, cacheability IS a big factor as the client implicitly caches a local copy of the resource data at least for a time.\n<\/blockquote>\n\n

Sure, it is important, but as a side effect of the client maintaining the state\n(i.e. the interaction being stateless). If the style were said to “revolve around”\nanything, this (statelessness) could be one of the big things, sure.<\/p>\n\n

\nI am not sure Roy Fielding’s dissertation would agree with your assertions here, Mark – see bottom of page 14:\n<\/blockquote>\n\n

Roy’s comment about combining styles doesn’t suggest how<\/em> styles are combined.\nAs I see it, if you’re using an architectural style with constraints A, B, and C which yield\ndesirable properties X and Y, and then you want to add property Z which is known to be obtained\nvia constraints D and E, then in order to get Z without giving up X and Y, your new style\nneeds to have constraints A, B, C, D, and E.<\/p>\n\n

FWIW, this model of constraints and properties has been around for some time, since\nat least Perry and Wolf’s\n“Foundations for the study of software architecture”<\/a> (using that terminology, anyhow). Some of the folks you quote, like Shaw,\nGarlan, Kazman, etc.. have accepted this model. I don’t see how what I’m saying is\ncontroversial in this regard.<\/p>\n\n

I’m glad to hear you’re giving the presentation again, and I look forward to\nfollowing up on this with you.<\/p>","protected":false},"excerpt":{"rendered":"Jorgen responds to my comments on a presentation he gave last week. Re my comment that architectural styles are pattern languages, not patterns, I can only point to Roy’s dissertation on this, where he suggests the association between an Alexendar “pattern language” and an “architectural style”, by suggesting indirectly that both are a system of […]","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[40],"class_list":["post-96","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-xml"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/96","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=96"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/96\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=96"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=96"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=96"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}