RE: REST; good for humans and machines

> > You mean the distinction between getLastShardPriceOfIBM and
> > http://www.stockquotes.com/ibm/lastsharedprice (typo repeated)?
> >
> > In the first case the service can report that the operation is
> unknown and
> > list all (say 10?) operations it supports.
> >
> > In the second case the service can report that the URI is
> unknown and list
> > all (10,000?) URIs it knows of.
>
> Any reason for choosing those particular numbers?

Total laziness on my part. Assume 50 stock markets with an average 200
companies traded in each market. Ignore options, warrants or futures. I'm
most probably totally off base here, I'm just illustrating different scales.
But in another application you may have tens of thousands of patient records
and five operations you can perform on them, or tens of thousands of
invoices and five operations you can perform on them.

Of course, you wouldn't be returning a list of URIs for patient records or
invoices if you don't trust the requester. And you don't trust the requester
even if the requester is another application running in the same network.
You wouldn't want the HR person in a clinic to have access to your medical
record?

But this is touching on a different topic on a separate thread that was
discussing trust boundaries and forgetting that trust boundaries exist even
within the same organization, even between two computers sitting next to
each other in the same server room.


> > Not that it makes one typo superior to the other, but perhaps
> there's some
> > hidden distinction here that could actually represent a compelling
> argument
> > to favor one approach over the other in a different, less marginal, use
> > case.
>
> Well, if I (as client) lifted that string out of  a response I
> just received
> a few
> milliseconds ago, it would seem to stand a high chance of being
> the correct
> string.  But there are other ways of getting it correct also.  That's the
> distinction
> that I value.

Just pointing out that there is a distinction between an approach that makes
each data item a resource and one that make a resource a means to access a
data item. And in this example it is totally insignificant, but in other
examples it is signficant. But I think we discussed this point to death
before.

My point of contention is that there are discussing two ways of doing
things. And I value - and agree with the example you gave before and with
Roy - that one approach would be superior in certain applications. I just
don't believe the WS architecture should enforce one approach or preclude
the other.

arkin

>
> Walden
>
>

Received on Sunday, 5 January 2003 23:56:33 UTC