{"id":353,"date":"2004-04-30T12:27:00","date_gmt":"2004-04-30T16:27:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/?p=320"},"modified":"2004-04-30T12:27:00","modified_gmt":"2004-04-30T16:27:00","slug":"restful-jeff","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2004\/04\/restful-jeff\/","title":{"rendered":"RESTful Jeff?"},"content":{"rendered":"

He writes<\/a>;<\/p>\n\n

\nPer my earlier note, I have evaluated my feelings on the units of REST:\n<\/blockquote>\n\n

and goes on to “support” or “strongly support” all of the high level\nmandatory constraints of REST.<\/p>\n\n

He also offered some very insightful observations on some of the\ndifferences between REST and Web architecture;<\/p>\n\n

\nREST is a single candidate architecture. And an architecture must be evaluated on the whole, rather than the individual parts. Fielding does a great job of stating that every decision in the candidate architecture has trade-offs. He further identifies the applicability of the architecture (distributed systems, system ‘feels’ stateless, desire to scale, desire to evolve, etc.) Like all candidate architectures, one can only evaluate the architecture against a problem that you are trying to solve. REST by itself can not be evaluated, only evaluated as a candidate solution to a pre-identified problem.\n<\/blockquote>\n\n

Yes, exactly. Which begs the million dollar question; do you think it applies\nto machine to machine integration problems? If so, then I’d say that makes\nyou a RESTafarian. Understanding the domain of applicability of an architectural\nstyle is very important; it’s not enough to believe, say, that “REST is great when\nyou’re building Web apps for humans”; you’ve got to be able to see beyond that.\nAt least IMHO, since I coined the term “RESTafarian” 8-) (which I’m sure I’ll\nregret at some point 8-)<\/p>\n\n

\nWhat was interesting to me was the lack of association between REST and HTTP, or more precisely the ‘verbs’ of HTTP. Instead, Fielding places significant attention on the need to use Resources (think URI), Self Descriptive Messages (think XML), but does imply that a generic interface is required. Somehow… I find myself agreeing with Fielding but disagreeing with many RESTifarians (I’m not sure how this is possible). Fielding suggests a “a uniform interface between components “, however he never mandates what that interface should be – only stating the characteristics.\n<\/blockquote>\n\n

Modulo the “think XML” bit<\/a>,\nyep. But this is actually one of my very few beefs with REST; the methods do matter.\nRoy and I talked about this (darn, can’t find the message in rest-discuss);\nthat there should only be one “get me the state of this resource” method. He made some\ncomment about how he didn’t want to list the obvious constraints. But as I’ve discussed,\nI think that’s quite non-obvious<\/a>\nto a lot of smart folk.<\/p>\n\n

\nHowever, I find significant ‘folklore’ stating that the interface is, “…defined completely and solely by the specified semantics of HTTP, i.e. GET \/ PUT \/ POST, etc.” (Jeff Bone) He continues to argue, “*there are no applications you can think of which cannot be made to fit into the GET \/ PUT \/ POST \/ resources \/ representations model of the world!*” The only issue I have is his term “made to fit” – meaning, what was the price of ‘making something fit’?\n<\/blockquote>\n\n

Very much agreed. Jeff sounds like he’s talking about GET\/PUT\/POST\/etc.. as a 100%\nsolution, but I think it’s more like a 97% solution, at least for “loosely coupled,\ndocument exchange” style solutions. As I mentioned to Jeff offline, in all my\nexperiences with HTTP, only once have I ever had to use an operation other than\nGET, PUT, POST, or DELETE (or\nMONITOR<\/a>)\nin order to get something done in a reasonably efficient way; that was to basically\nimplement the functionality of a SQL UPDATE over a large set of resources (a PUT to\neach resource would have been prohibitively expensive).<\/p>","protected":false},"excerpt":{"rendered":"He writes; Per my earlier note, I have evaluated my feelings on the units of REST: and goes on to “support” or “strongly support” all of the high level mandatory constraints of REST. He also offered some very insightful observations on some of the differences between REST and Web architecture; REST is a single candidate […]","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-353","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\/353","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=353"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/353\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=353"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=353"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=353"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}