[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
>
> ...
>
> OK, I think something is beginning to penetrate ... REST is an
> "architectural style" of which HTTP is an instance.
I wouldn't say that. REST is an architectural style of which particular
systems are an instance. The glib thing to say is that the Web is the
primary instance of the REST architectural style. More concretely, eBay,
Google and any other web application you use is an instance. HTTP is a
protocol that is optimized for handling that instance.
> ... A reliable
> messaging infrastructure for web services could be described in that
> architectural style, but that is not the same as saying that HTTP as
> implemented in IIS/Apache/etc. could support that messaging
> infrastructure.
These issues are subtle so getting to a point of Zen makes us all feel
dense. REST is an architctural style. Remember how dense you felt
learning object oriented or functional programming? Remember how you
probably kept saying: "Yeah, but how would this style handle my problem
X, Y or Z?"
> ... Is that more or less correct? Sorry if I'm being
> dense ....
I would say: All IIS and Apache do is handle a request and hand it off
immediately to your servlet or CGI or whatever. So yes, you can do
reliable messaging in a servlet or CGI or whatever within Apache or IIS.
> As a concrete example, consider Miles Sabin's scenario of a web
> service that takes hours to complete because of some human
> intervention being required. It *would* be easy to envision this
> being implemented with an SMTP message invoking the service and
> another SMTP message returning the result. On the other hand, this
> could be implemented as an HTTP PUT of the request to the provider's
> server follwed by a PUT of the response to the requestor's server. Or
> the requester periodically doing a GET to the requestors server to
> see if the response is done. Sounds a lot like SMTP and POP to me
> ... am I missing some fundamental reason why SMTP/POP is
> "asynchronous" and HTTP is "synchronous?"
No, I think you're gaining some Zen. The next time someone says that
HTTP cannot handle asyncronous applications, ask them what they mean by
that. It can do so to the same extent that other protocols can.
> ... Doesn't the intrinsic
> sychronousness adhere in the application level, not the protocols
> themselves?
I would say so!
> Anyway, my point here is that it would seem that reliable messaging
> infrastructures for web services don't need new underlying protocols,
> they need a different coordination mechanism, i.e., queuing, caching,
> forwarding, filtering....
I agree.
Paul Prescod
|
