- From: Joshua Allen <joshuaa@microsoft.com>
- Date: Tue, 26 Mar 2002 12:55:58 -0800
- To: "Paul Prescod" <paul@prescod.net>, <www-tag@w3.org>
> > ... That URI is not > > addressable in any other form than GET, and is essentially using GET as > > an RPC mechanism. > > It uses GET for GET. That's REST. It uses a URI to address an itinerary. > That's REST. There is no RPC involved. > > When I go to that page, it allows me to also submit information. It uses > POST. That's REST. The only mild transgression against REST is the use There is more than that -- does the POST actually go to the same URI? Why do you POST against URI "y" to modify resource "x"? If I can GET a resource, and I own it, I should also be able to PUT it. If GET is the only thing that actually works RESTfully against the majority of URIs, then I contend that we haven't really got REST yet. My dream is that every resource that supports GET can also support PUT, and can reliably be part of triples that describe metadata about that resource *independent* of the resource. SOAP is about sending a message to an endpoint, with no semantics about whether that message will invoke RPC, change the resource associated with that endpoint, etc. > For the types of things where we have to choose SOAP-RPC versus REST, > there will be no "URL bar" and the "peeping toms" will be intermediaries > that can snoop on the body as easily as the URL. OK, I think you missed my point -- the point is that *most* sites do things like assign temporary session keys to their users, and the "resources" being represented are dependent on that "session" key. Whatever token is embedded in the URL or cookie is used to determine user context and manage the "sensitive" data on the other side. All access to resources is controlled through business logic and user-specific context. This desire to avoid exposing resources through URIs is just one reason that people design systems in a way that hides *functionality* behind URIs rather than *resources*. When I say that I like the ideas of REST, I am talking about the cases where you actually expose *resources* through URIs, and I want it to look like I described above. I am just pointing out that it is unreasonable to ignore the people (or their reasons) who hide *functionality* behind URIs. And there *is* a difference -- please don't tell me that "exposing functionality is just an example of REST, since the return value is a representation of a transient state." I think a "resource" needs to meet a higher bar than just "you can do a GET on it", because then a resource is not distinguishable from an RPC request. And in fact, this is why I think we have a problem today -- most people use GET and POST with things like PHP, ASP, etc. as an RPC. They tell themselves, "everything I have done here with GET and POST I could just as easily do with RPC". Precious few people even bother to make their dynamic pages addressable through bookmarks, let alone metadata. And this is not even talking about other ways that you *should* be able to use a "resource". > No argument here. We need to improve education and re-evaluate what in > the infrastructure is leading people awry. Well, for starters I think that (lack of) bidirectional symmetry is horrible. POST is not very RESTful anyway, IMO, and more systems should support PUT. Next, there is no good infrastructure in place for referencing metadata about a particular URI. Google ":link" search and the bookmarks menu in your browser are the only ones that are common. Just the lack of these two things, IMO, severely cripple the *value* of URIs to the average person. To the average person, GET and POST are the only valuable uses of a URI, which encourages him to think of URI as an RPC endpoint. If people had some more valuable uses of URIs that actually depended on the URI being a more reliable resource reference, then maybe the problem would take care of itself (since users would punish providers who failed to provide reliable, universal addressability, and customers would reject products that did not provide bidirectionality). > > .... If you want to fix that problem, SOAP is > > the least of your problems, and more likely an ally. > > How so? Well, it makes it less likely that people will use the GET querystring overloading to pass RPC-like parameters. In other words, I want to have some degree of confidence that when I GET a resource, I can also PUT it (given appropriate permissions). If people stop overloading the querystring with RPC parameters, I improve my chances. Maybe there are others... > SOAP demonstrably discourages people from RESTful architectures in that > a SOAP (e.g.) getStockQuote is NOT REST-ful and one cannot do a REST-ful > GET of a STOCK QUOTE without abandoning SOAP. I'm still waiting for an Is it the stockQuote example that bothers you? I have no strong opinion about whether that should be a resource GET or an RPC call. But the point is, GET of a resource makes sense for some things, and in other cases, developers will insist on hiding all of their resources behind an endpoint that exposes *functionality*. Maybe you can argue that some places where a person uses RPC or Message-passing should really use GET. But you cannot argue that *all* message-passing architectures should use GET. And users wouldn't listen anyway. In other words, being able to pass a message to a URI and allowing the URI to opaquely act upon that message *is* a legitimate use case. You cannot ignore this use case. > example of a SOAP web service that uses URIs properly. Pointing to flaws > elsewhere is really not, in my opinion, relevant. Well, can you point me to an example of a POST web service that uses URIs properly? Then take that example and just use SOAP as the envelope when POSTing. There are quite likely web services in production that meet that criteria (although I dunno, since it depends on what you mean by "uses URIs properly).
Received on Tuesday, 26 March 2002 16:15:05 UTC