Flutterby™! : REST 2002-05-10 17:12:16+00

REST

2002-05-10 17:12:16+00 by TC 6 comments

I've been catching up on a lot on missed reading thats been stacking up for the last few months and recently discovered REST. I found myself nodding and going "Yeah Duh" a lot (picture yourself reading a newspaper and seeing an activist group advocating round tires). I don't want to try to take away from the guy making square tires because exploration is cool. On the other hand do we need a new group and new acronym to remind us that round is cool? here is some example code of a web interface done first in SOAP & XML-RPC and then the old REST way. I know there are some SOAP & XML-RPC fans out there, why would one change from REST???

Okay, I can't take it any more... What the hell is a Wiki?! I've done some poking around, trying to find out. But I don't seem to be able to find a definitive answer. It seems to be part documentation project/part blog, but I don't understand how or why - not to mention; is there some kind of standard/protocol that defines a Wiki?

Wiki now refers mostly to the style, with hundreds of implementations. With wiki, every page of the site is editable by anyone. Most pages end up either being in "documentation style" (coherent coverage of a topic) or "thread style" (discussion), often (and hopefully) the latter will be refactored into the former, preserving all the real meat while making it easier to read for the first time reader.

Wiki pages are just plain pages, most everything else done with them is based on convention, sometimes aided by a little code -- like creating a blog in a wiki.

Almost all Wiki's use "structured text" for markup instead of HTML, which makes page editing very easy.

We don't need a Round Wheel Appreciation Committee, unless they're also going to produce easier REST APIs, or make the real distinction between the two.

Compare the SOAP call with the "REST" call on page two of that article: the "RESTful client" is much more programmer work than the SOAP client. On Dave Winer's own platform, you'd do that with SOAP thus:

whereas with REST you'd have to muck about with tcp.httpClient, which is at least as big a difference as in the Perl example. How big is the difference in Python and other environments? It's not only the hype that's causing SOAP and XML-RPC use, but that its advocates have made it so easy: the draw of procedural web services is literally that you can make computation occur on some other computer through HTTP with only a function call.

That whole argument doesn't get into the *theoretical* difference between REST and SOAP/XML-RPC, which is that the latter are procedure calls and REST is more like object orientation. With SOAP you say, "Compare these two files," but I imagine with real REST you'd write, "Here are these files" with two HTTP PUTs and "Compare these resources" with a POST.

Putting it that way, I'd use SOAP for "compare these two files"--but there's a whole slew of work for which REST is better conceptually suited, like "compare these two resources you already have." It's not really fair to compare how you'd do a procedure call with a procedure call protocol to how you'd do a procedure call with Representational State Transfer. They should be perfectly able to coexist like procedures and OO do.

Ken; thanks for the link. It just seems like far too much chaos and noise for me. I like more structure in my communication (okay, I like more structure in just about everything).

the cool thing about kip's article is how it uses SOAP::Lite and CGI::XMLApplication to provide multiple interfaces to the same underlying functionality. the only other platform i've heard of that approaches that ease of implementation on the server side is .net. and wsdl-consuming environments can make it similarly easy to switch underlying implementations on the client side.

(i don't think the example from kip's article is a particularly good one in demonstrating the differences between the rest and rpc approaches. there's much better examples in the restwiki.)