Mark Baker wrote: > > > On 1/18/07, Gregg Wonderly <[EMAIL PROTECTED] <mailto:gergg%40cox.net>> wrote: > > > It's a feature of REST, by definition. > > > > No, REST transfers the content, it doesn't specify that it's possible > to then > > make connections to the network, or how that is done. How that is > done, is a > > programming API. > > REST is an architectural style. You seem to think it's HTTP or the > Web, or something else concrete. Architectural styles are abstract, > and so if one - like REST - says it includes a mobile code constraint, > then by golly it includes a mobile code constraint.
Yes REST is a style, which embodies a state/document transfer system. The description of mobile code in what you pointed at, was not something that REST favors or enables in more readily than some other document type. The client, receiving the transfered data (via GET), then decides what to do with that content. In my web browser for example, I can download a JAR file, and choose to invoke it, or to save it to disk. That has nothing to do with REST/HTTP. It has to do with client functionality. That functionality could be implemented regardless of the use of REST/HTTP as the transfer mechanism. Thus, REST/HTTP is not an "enabler" of mobile code. It is an enabler of content transfer, which in some case might be mobile code, but the fact that any particular document type represents code is something that the client determines, not REST. Gregg Wonderly
