- From: Chris Chapman <chris@pentandra.com>
- Date: Tue, 13 May 2014 11:29:20 -0600 (MDT)
- To: Markus Lanthaler <markus.lanthaler@gmx.net>, Gregg Kellogg <gregg@greggkellogg.net>, Thomas Hoppe <thomas.hoppe@n-fuse.de>
- Cc: public-hydra@w3.org
OK, I think the main points of my argument have been scattered across a few emails, so I'm going to use the convention Markus set forth last month so we can address this issue in a more organized way. I will try to include select rebuttals from the previous thread that I thought were pertinent for discussion. Feel free to add any other arguments that I overlooked. I'm hoping that bringing together everything into one place, it will make it easier to understand what the real issues are regarding this question. Apologies for jumping the thread. I think we have been missing the point in the discussion so far, and its possible we're talking about two different things, so I'm hoping that this discussion will help narrow down and focus the approach we're taking with the specification, whatever the final decision may be. MY PROPOSAL: The main point of my proposal to use "Action" instead of "Operation" is based on whether the spec should talk from the perspective of the client or the perspective of the server. If the Hydra spec is server-focused, it makes more sense to talk about a complete logical operation. If Hydra is client-focused, it makes sense to talk about the server's capabilities from the client's perspective. MY SUPPORTING ARGUMENTS: 1. The client can't complete a logical operation on its own. While Hydra can give hints about the response to an HTTP request (which I think is great), the client can only recommend changes to the server. Inevitably, it's up to the server to accept them or not and complete the operation. 2. The Collaborative International Dictionary of English defines action as "the effect of power exerted on one body by another", preserving, in this context, the semantic understanding that one agent (the client) interacts with another agent (the server) over the web. 3. I would argue that operations happen on the server [1], and are an server-side implementation concern, irrelevant to the client. 4. As a client-side developer, I would want to know which actions I can take, rather than which operations the server supports. 5. "Action" is more in line with what Roy Fielding said, that hypertext is "the simultaneous presentation of information and controls such that the information becomes the affordance through which the user obtains choices and selects actions" [2]. MY RESPONSES TO OTHERS SO FAR (newest first): On Tuesday, May 13, 2014 10:01:26 AM, Gregg Kellogg wrote: > > I agree that "operation" implies an action which is completed, whereas > "action" implies the triggering event. However, given that HTTP > actions/operations return a status code, this usually (but not always) > implies that the action has reached some form of completion. > Yes, I agree with this understanding of Operation and Action, but we need to be sure that we do not hide the underlying mechanism (HTTP) from the client. In the end, we're dealing with (two) components and their interactions over a network. The client only needs to know how to do its own action, though having hints of possible status codes helps the client understand the server's response. [...] Markus Lanthaler wrote: > On Monday, May 12, 2014 11:50 PM, Thomas Hoppe wrote: > > On 05/12/2014 04:58 PM, Markus Lanthaler wrote: > > > As you know, that's in fact one of the first issues I raised: > > > > > > https://github.com/HydraCG/Specifications/issues/2 > > > > > > ... but so far you are the first one to mention this. The reason it is > > > called Operation is > > because in the end it describes a HTTP operations (or requests). I have no > > strong opinion on > > this and would like to hear other peoples thoughts on this. > > > > Looking to the HTTP spec, there is no thing called "HTTP Operation"; the > > spec speaks about methods (GET, PUT, POST...). > > You are right. The term operation was mostly eliminated from httpbis. It was, > however, used quite a bit in RFC2616 in statements like: > > "This feature is intended to be useful in preventing races between PUT > operations." > > "If the requested resource has not been modified since the time specified > in this field, the server SHOULD perform the requested operation..." > > "The client cannot be guaranteed that the [DELETE] operation has been > carried out, even if the ..." > > But it doesn't really matter IMO. > If you look at the context of these statements from RFC2616, they are all talking about server-side operations. The HTTP spec uses the term action to represent client-side requests to the server. [...] On Monday, May 12, 2014 3:49:58 PM, Thomas Hoppe wrote: > My mental model about this is, exemplified with a user registration. > Say a new account is registered by a HTTP POST with certain data. > > So the caller conducts a _create operation_ using the HTTP POST method. > The action is the event that happened at the point in time when he > conducted > the operation. The operation is not a single point in time, it has a > start and an end. As tempting as it is to think of the create operation as one logical operation with a start and an end, how would you translate this into HTTP? Chris Chapman Pentandra [1]: Even the Hydra spec makes the assertion that "a client has to know which operations the server supports", implying that it is the server that does operations. http://www.hydra-cg.com/spec/latest/core/#adding-affordances-to-representations [2]: http://www.slideshare.net/royfielding/a-little-rest-and-relaxation (slide #50)
Received on Tuesday, 13 May 2014 17:30:12 UTC