- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Thu, 24 Jan 2013 11:40:09 -0500
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
hello andy. On Jan 24, 2013, at 14:24, "Andy Seaborne" <andy.seaborne@epimorphics.com> wrote: > On 24/01/13 08:50, Wilde, Erik wrote: >> as an illustration, let's look at a very simple example: let's assume a >> product catalog and each product page has an "order" link that requires >> customers to just POST their address, and then they're ordering that >> product > What happens if you GET that link? e.g. is it an LDP-R? it was just an example i made up, so i don't really know. you could disallow GET in the protocol, then they'd get a "method not allowed." you could also define the protocol so that a GET would result in a collection of past orders. that's the crux: how the interaction model maps to the data model (the server state) in the back end has a lot of freedom and design options to it, resulting in different protocols. > I think it would be more accurate to qualify the word link such as a > "service reference". The word 'link' is overloaded including in "linked > data" with different nuances. (service link is OK) i am certainly using "link" in the REST sense: references that clients are expected to follow in their application flow, and where the behavior is defined by the protocol (the media type). if that may cause confusion, what about hyperlink, following the recent trend that one of the essences of REST is that it's hypermedia? cheers, dret.
Received on Thursday, 24 January 2013 16:41:01 UTC