[
Lists Home |
Date Index |
Thread Index
]
> 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...
3. I don't understand the rationale for principal #2; what's the
reason to prefer one of these three?
.../parts/345
../part?234
../part?id=345
Yes, I removed the "get" word; once I do that, what's the issue?
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
getprice/ms-office/98
getprice/ms-office/xp
but why not
getprice/xp/ms-office
? And does REST tell me how to specify the ordering? Either way, it
seems arbitrary and limited compared to
getprice?prod=ms-office&version=xp
doesn't it?
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?
#6 seems to contradict classic distributed systems practice (and, say,
gigabit networking) which seeks to minimize round-trips. Doesn't it?
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.)
>REST describes what makes the Web work well.
Ah, the crux of my problem with the REST camp. Post hoc propter hoc.
Thanks.
/r$
|
