Re: ISSUE-2: Use the term Action instead of Operation

Hi, Thomas

Responses inline :)

Chris Chapman
Pentandra


----- Original Message -----
> From: "Thomas Hoppe" <thomas.hoppe@n-fuse.de>
> To: "Chris Chapman" <chris@pentandra.com>, "Markus Lanthaler" <markus.lanthaler@gmx.net>, "Gregg Kellogg"
> <gregg@greggkellogg.net>
> Cc: public-hydra@w3.org
> Sent: Tuesday, May 13, 2014 11:42:47 PM
> Subject: Re: ISSUE-2: Use the term Action instead of Operation
> 
> Hi,
> 
> On 05/13/2014 07:29 PM, Chris Chapman wrote:
> > 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.
> As outlined in my previous mail, I have a different thinking: The agent
> wants to make an action happen and
> he tries to do so by performing an operation with its counter agent
> (server).

I'm not exactly sure whether I'm understanding you correctly here, but if we hide the fact that these operations are happening on the other side of a network we will be adding another level of indirection to the client developer's mental model. 

Your comment does bring up a fundamental question that I've had about Hydra. Is Hydra a cool, dynamic WADL that clients can do service discovery on (that happens to use hypermedia), or is Hydra a real application programming interface designed with the client's happiness in mind? Yes, it's just a difference of one word, but on each word hangs a completely opposing perspective. One focuses on describing the server's capabilities and the other focuses on describing actions the client can take. This decision goes deeper than choosing between synonyms. IMHO, the latter would be much more powerful (and more RESTful). Thoughts, anyone?
 
>
> > 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.
> 
> As mentioned in my first mail, I checked this HTTP 1.1 spec document [1]
> and it uses the term "method" for its verbs. Apart from that it is also
> talking about
> actions I have to agree. E. g.:
> "The action performed by the POST method might not result in a resource
> that can be identified by a URI."
> I suspect that Roy may not have considered the different meaning of
> operation and action
> when I wrote that.

I'm not sure I understand the relationship between HTTP methods and the current discussion. Could you elaborate?

> 
> >
> > [...]
> >
> > 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?
> 
> The operation is performed between the request reaching the server and
> its response.
> Or it may take longer and the server may decide to return a 303 See
> Other [2]
> answer with a location for the client to obtain the progress of the
> operation.

So it sounds like we are in agreement that operations happen on the server.

> This implies that the client must have the concept of an operation which
> has
> a duration.

Yes :-), and I would argue it's the client's job to manage the underlying HTTP interactions, not Hydra's. Hydra describes the possible actions the client can take, it can't manage an operation on it's own---it's a description language.

> 
> >
> >
> > 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)
> 
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
> [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
> 
> 
>

Received on Thursday, 15 May 2014 19:29:41 UTC