[
Lists Home |
Date Index |
Thread Index
]
Dave Winer wrote:
>
> BTW, last time I checked HTTP was synchronous.
>
> Maybe I missed something.
What do you mean by synchronous? Is SMTP asynchronous? If so, so is
HTTP:
* http://www.prescod.net/asynchhttp.html
I would agree that there are protocols which are deeply asynchronous,
unlike SMTP and HTTP. But most people, when they say asynchronous mean
SMTP and HTTP is just as asynch as SMTP.
> Paul those are good compelling points, had they been raised before we built
> an infrastructure for XML-RPC and SOAP at the script level.
>
> Earlier this month we finally implemented the top of the stack, something
> called SCNS or Simple Cross-Network Scripting, which makes calling a web
> service as simple as calling a procedure (yes it looks a little different,
> and that's good, imho, people should know when they're making a networked
> call.
REST is admittedly not about cross-network scripting. REST is about
building web services. Here's what I see as the difference: with
cross-network scripting you are trying to hide many of the differences
between making a local call and making a remote call. That's great for
ease of use but it sacrifies a bunch of stuff in terms of
addressability, scalability, peformance and potentially security. I am
totally in favour of this trade-off where it makes sense. I advocate
XML-RPC as a viable alternative to REST with the caveat that I am
nervous about its reliance on "ASCII" and a few other things like that.
REST is about taking the networking issues most seriously. This means
that the interface to networked code is different than to local code.
Not harder, but different. Both client and server have to think
differently when they access networked code. You could paper over the
differences on the client side with an OO library but this might
introduce performance or reliability problems.
In my mind, web services are about doing the sorts of things we couldn't
do with COM or CORBA (otherwise why invent a new buzzword) so I don't
see XML-RPC (or SOAP RPC) as a Web Services technology. I am happy to
promote XML-RPC as a cross-network scripting tool, however, and I have.
>...
> Also I really appreciate the offer to convert Manila-RPC to REST, but let's
> look forward. I'll keep my eye open for an opportunity to use your
> principles in putting together a new service, and I'm sure it'll be easy and
> perform well.
>
> How does that sound??
Okay, give me a shout when you find something. If it isn't private maybe
we could do the design in the open so that we'll have another example of
applying REST to a problem. But consider that according to my dichotomy
above it probably makes sense to have both a REST and an XML-RPC
interface to some services...you might find that having both in Manila
is a competitive advantage. For instance I'd bet that after we
REST-ified a service you would find that many tools become Manila
clients "for free"...e.g. Emacs, wget, MSWord and Internet Explorer!
Paul Prescod
|
