[
Lists Home |
Date Index |
Thread Index
]
On Fri, 2006-02-24 at 14:41, Bullard, Claude L (Len) wrote:
> Agreed. If the network definitions are semantically simple,
> the communications load is in the resource definitions and
> negotiations of the meaning of signs (from a semiotic perspective).
>
> I think it comes down to explaining that network definitions
> (verbs for schlepping stuff) are never *meaningful*. It's like
> asking your mailman to do your taxes instead of moving the
> form to the IRS and bringing the payment back. (We may have some
> fun later merging this thread into Pragmatics (not what
> Box is talking about but the subfield of linguistics)).
This is more along the lines of what I was talking about. I wasn't
trying to imply that naming was easy. I was more referring to the
classification of something which is chosen to expose it via a REST
interface--specifically in the context of a complex application which
was beyond the bounds of something like an order, a tree, a bird, a
human, web page, etc.
What I needed was to kinda stand back and squint at my particular
problem to figure out how to classify something that could have been
looked at from a number of perspectives, because I thought the obvious
choice was too fuzzy a concept to sensibly represent via the standard
HTTP verbs. It was more of a mechanism or process, rather than your
typical resource. Actually, in this particular case, the naming was
easy, but figuring out something sensible that the name represented and
would play by the rules (POST/PUT/GET/DELETE) was difficult. In the end
it took two abstractions: the mechanism and something else which was
really there just to support the access semantics.
In Len's example above, which is most important: who you ask, or what
you're asking them to do for you? In one scenario (security and trust
issues aside), you could say you wanted to pay your taxes because that's
the abstraction you were using. If your postman accepted your box of
receipts, knew to take them to your account who would then prepare your
tax return for you and then deliver it to the IRS, you *could* logically
ask your postman to do your taxes--even though that's not his job. Of
course, knowing that your postman could do this (or that he even was a
postman, really) brings you back to your semantics vs. pragmatics point.
>
> Why Federated instead of Confederated? In other words, if
> REST is Federated naming, you are saying it is centrally
> administered. I'd say it is Confederated because the
> meaningful names are in the packages, not the types of
> the envelopes.
I have to agree with this as well. The access to the package is the
same, but you don't know what it is until you look at the manifest.
Factor in security policies, and you can't always look at the manifest
(or even see the package). Again, I'm thinking about this in more of an
application-specific view rather than specifically in the context of the
web. Of course, I can see how Peter's recursion argument comes into
play here as well: "if I had an Index File, I could look up how to find
the index file under 'Index File'!" (for the Dr. Who fans out there).
ast
>
> From: Richard Salz [mailto:rsalz@us.ibm.com]
>
> > But I think the hardest thing to understand about REST isn't the
> > semantics of the operations per se, but how exactly to define what the
> > resource is so that the operations make sense.
>
> Yes, naming in distributed systems has long been recognized as a a very
> important, subtle, and hard problem.
>
> I used to say REST is just federated naming, but nobody understood me.
***************************************************************************************************
The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
|
