[
Lists Home |
Date Index |
Thread Index
]
Jeff Greif wrote:
>
> Why isn't it a RESTful solution to have the client encrypt the data (using
> an applet on the original page, or some Javascript or something else) and
> POST the encrypted data (encoded in base64 if necessary) to the HTTP server?
What if the semantic of the action was GET? And how will you say which
resource you are posting to without telling the software doing the
mapping from resources to logical objects?
If the only thing that is double encrypted is the entity body, but the
URI, headers and method are all SSL encrypted, then you would start to
see *some* of the benefits of REST.
As I've said, HTTP has no problem with this. But REST is an
architectural style. You either adhere to it, if you are allowed to, or
use some other architectural style if one has already been selected by
law or fiat.
Here's a similar question: "I've got an object database and I want to
access the objects in it as objects and post method calls to them etc."
Sure, HTTP will allow you to do that. But if you've already committed to
the object/method style of network programming then there is no role for
REST. If you stated your problem in terms of business needs then REST
could apply.
--
Come discuss XML and REST web services at:
Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
|
