{"id":278,"date":"2004-02-13T11:24:00","date_gmt":"2004-02-13T15:24:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/?p=278"},"modified":"2004-02-13T11:24:00","modified_gmt":"2004-02-13T15:24:00","slug":"savas-on-rest-again","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2004\/02\/savas-on-rest-again\/","title":{"rendered":"Savas on REST again"},"content":{"rendered":"

More good\ninsight from Savas<\/a> on REST.<\/p>\n\n

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

\nThe human factor is involved. If a resource (e.g., a web page) has moved, applications don’t break. It’s just that there is nothing to see. We are frustrated that it’s not there. If an application depends on that resource being there, that application breaks.\n<\/blockquote>\n\n

Yep. But how is that any different than a service which you depend on not\nbeing there? At least HTTP responses code are well-defined, and handle a lot\nof common cases, including redirection, retiring, retry-later, etc.. I don’t\nsee how this is human-centric at all; it’s just dealing with inevitable\nerrors in distribution across trust boundaries.<\/p>\n\n

I’m not sure what he means by using HTML for “interfaces”, but he then\nlater speaks my language again when he describes HTML as a format for\ndescribing resource state;<\/p>\n\n

\nIf a resource’s representation is described in HTML, all is fine. Everyone knows how to read HTML. How about an arbitrary XML document though? Did we have a way of specifying to the recipient of the resource’s representation about the structure of the document? Perhaps they wouldn’t have requested it if they knew about it.\n<\/blockquote>\n\n

XML is fine and dandy, and I use it whenever I can, but it’s just a\nsyntax. As such, it doesn’t do anything to alleviate the issue that\nunderstanding an XML document is an all-or-nothing proposition. That’s\nwhy when I use XML, I almost always use RDF. It enables a machine to\nextract triples from an arbitrary RDF\/XML document, and triples are much\nfiner grained pieces of information than a whole document. It allows me\nto process the triples I understand, and ignore the ones I don’t, which\nanother way of saying that it provides a self-descriptive extensibility\nmodel. See this example<\/a>.<\/p>\n\n

\nIf we are going to glue applications\/organisations together when building large scale applications, we need to make sure that contracts for the interactions are in place. We need to define message formats. That’s what WSDL is all about.\n<\/blockquote>\n\n

Agreed, but that’s also an important part of HTTP. It just defines message\nformats in a more self-descriptive way (i.e. that doesn’t require a separate\ndescription document to understand what the message means).<\/p>\n\n

\nAlso, we talk about exchanging messages between applications and\/or organisations. Do we care how these are transferred? Do we care about the underlying infrastructure? I say that we don’t; at least, not at the application level.\n<\/blockquote>\n\n

I’m not sure we’ll get past this nomenclature problem, but in my world, documents are\ntransferred while messages are transported. I do agree that how message transport occurs\ndoesn’t matter, but I don’t agree that how document transfer occurs doesn’t matter.\nAs an example, consider a document transferred with HTTP PUT, versus that same document\ntransferred with HTTP POST. Both messages mean entirely different things (more below).<\/p>\n\n

\n

If there is a suggestion that constrained interfaces are necessary for loose-coupling and internet-scale computing, then here’s a suggestion… What if the only assumption we made was that we had only one operation available, called "SEND"? Here are some examples:<\/p>\n\n

TCP\/IP:SEND, CORBA:SEND, HTTP:POST, EMAIL:SEND, FTP:PUT, SNAIL:POST (for letters), etc.<\/p>\n<\/blockquote>\n\n

Ah, this one again. 8-)<\/p>\n\n

You can’t compare TCP\/IP “SEND” with HTTP POST or SMTP DATA.\nTCP\/IP is a transport protocol and therefore defines no operations. You can put\noperations in the TCP\/IP envelope yourself (e.g. by sending “buyBook isbn:123412341234”),\nor you can have them be implicit by the port number by\nregistering<\/a> your “Book\nBuying” protocol with IANA, only ever using that one operation (“buyBook”), and\nsending just “isbn:123412341234”). On the other hand, HTTP, SMTP, and FTP, all do<\/em>\ndefine their own very generic operations.<\/p>","protected":false},"excerpt":{"rendered":"More good insight from Savas on REST. He writes; The human factor is involved. If a resource (e.g., a web page) has moved, applications don’t break. It’s just that there is nothing to see. We are frustrated that it’s not there. If an application depends on that resource being there, that application breaks. Yep. But […]","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-278","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\/278","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=278"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/278\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=278"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=278"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=278"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}