Lists Home |
Date Index |
[I'll jump in because I'm interested in understanding Rich's security
question. He's posed it to me before and I must not have understood it
Rich Salz wrote:
> > http://www.xfront.com/REST-Web-Services.html
> I read through this and have a couple of questions.
> 1. Why isn't the reference to Roy's thesis a hyperlink?
> 2. Is it a REST "requirement" that submitPO returns a URI for the
> stored document that the submittor can later modify? In the normal
> course of business you don't get to modify your PO willy-nilly...
I think that REST strongly counsels (or at least my REST designs always
entail) that something like SubmitPO return something addressable. After
you've submitted a PO the two parties will want an unambiguous way to
refer to it. On the Web, this is a URI. Addressability is the issue, not
Obviously most of the Web does not respond to PUT from random people and
that makes sense! Who can do a PUT on an existing resource (if anyone)
is a business rules decision.
> 3. I don't understand the rationale for principal #2; what's the
> reason to prefer one of these three?
> Yes, I removed the "get" word; once I do that, what's the issue?
Practically, there is probably not much of a difference.
But, the first is a reference to a resource. The latter two are queries
and (arguably) not resources in their own right. Queries have slightly
different semantics. For instance, queries are constructed by the client
whereas normal hierarchical URIs should be treated as opaque.
> 4. Suppose I have a "pricequote" feature that takes a product and
> version. An implication of #2 is that REST wants me to arbitrarily
> order those those attributes, as in
> but why not
> ? And does REST tell me how to specify the ordering? Either way, it
> seems arbitrary and limited compared to
> doesn't it?
In that case you really *are* doing a query. The *client* is
constructing a URI. It's a totally different situation. In one case you
are dealing with "real-world" namespaces and building URIs from them. In
the other case you are talking about a mechanism for constructing opaque
identifiers. Because the opaque identifier is opaque ? vs. / doesn't
matter much except that it implies that identifier is not really opaque.
> For item #4, just a clarification: the issue is that the GET doesn't
> modify the resource; I wouldn't expect a "getweather" URL to return the
> same thing all the time. Right?
> Suppose I need to fetch a resource such that only the endpoints can now
> the item being retrieved and the response. I can do the response easily
> enough, send xml-encrypted data. How do I send the request in a REST
> fashion? I think this is beyond the scope of REST, but am not sure; any
> thoughts? (Imagine requesting medical records; because of my "only
> endpoints" requirement -- imposed by us HIPPA regulations -- SSL will
> not suffice.)
Could you describe how SSL fails to satisfy? Here is my understanding of
how SSL/TLS works:
""The agent acting as the HTTP client should also act as the TLS
client. It should initiate a connection to the server on the appro-
priate port and then send the TLS ClientHello to begin the TLS hand-
shake. When the TLS handshake has finished. The client may then ini-
tiate the first HTTP request. All HTTP data MUST be sentas TLS
"application data". Normal HTTP behavior, including retained connec-
tions should be followed.""
How could that reveal any information other than "Machine with IP X set
up an encrypted connection to machine with IP Y and sent some data."
Am I looking at the wrong spec
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/