On 11/25/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > > What's interesting about this argument is an implicit assumption being > > made; that if you had an existing HTTP/URI based Web API, but then > > later found it needed "security, reliability, or transactions", that > > you need to abandon the existing Web API and replace it with SOAP. > > What about, oh, say, *adding* those ilities incrementally, within the > > constraints of the existing API? > > Hey great idea! OK now tell me, what exactly does one need to do to add > message level security to HTTP? After I sign the message where do I put > it so the recipient will always check that before touching the message?
I'm not quite sure what you mean there, but you have a number of options in this space. Not all are RESTful, but they still follow the most significant constraints. > > How about reliability? (Remember HTTP-R?) GET, PUT, and DELETE are as reliable as one would need, since they're known safe and idempotent (respectively). POST is neither of course, so any reliability solution would resemble a subset of a message-level reliability solution (minus the latency tradeoff). Stefan linked to some solutions, but my favourite is POE by Mark Nottingham; http://www.mnot.net/drafts/draft-nottingham-http-poe-00.txt > How about transactions? For reasons similar to those discussed here, transactions are generally undesirable between untrusted parties because the cost of resource reservation is prohibitive. That's not to say there aren't other aspects of transactions which don't have value in a REST context, but that's obviously too big a problem space to explore without an example in front of us. > > > OK if its easy then let's see the criteria. RESTafarians say cookies are > > > not RESTful etc.. How do you see a GET http://foo.com/xyz?a=b&y=10 and > > > say whether its RESTful or not? > > > > As you would answer any question of that sort; by looking at the messages. > > ?? No way. Only the owner of the resource can say whether this GET is > safe or not. How can you possibly say that by looking at the messages?! You're confusing two concepts here; the safety of GET, and what a particular server may or may not do in response to receiving a GET request. For the first part, RFC 2616 defines GET to be safe and nothing you can implement can change that. For the second part, what the server does is immaterial to the architecture, as long as it meets the expectations of a GET request; returning data corresponding to the provided URI. It's a common misconception that unsafe GETs are not RESTful. > > > Wait, how do you advocate REST as an implementation technology for > > > *service* oriented architecture when REST doesn't have the concept of > > > services but rather has the concept of resources? > > > > Because virtually all services can be used as resources (usually more > > than one resource per service though). > > So your proposal is to first make service, and then introduce resources > in front of services to make it RESTful and then, voila!, you have a > beautiful RESTful system? Um, why bother with that extra layer of > complexity when the underlying guts are service oriented already? By "service" I didn't mean "Web services", I just meant any provider of data or functionality that one might find on an intranet; databases, application-specific stores, file systems, content repositories, message queues, etc..They can all be wrapped as resources. Mark.
