Re: ISSUE-31: Are Operations violating REST's uniform interface constraint?

On 02/15/2014 09:33 PM, Ryan J. McDonough wrote:
> On Feb 15, 2014, at 1:26 PM, Thomas Hoppe <thomas.hoppe@n-fuse.de> wrote:
>
>>> The HTTP methods are fixed and already have a very generic, but well defined semantics that cannot be changed until the HTTP spec changes them. They cannot be subclassed or extended. Once a message leaves the client, this is JSON-LD request sent over POST and that’s all anyone sees when it’s in flight. At present, Hydra suggests that we can subclass the HTTP methods with additional semantics. Take the following example:
>>>
>>> {
>>>    "@context": "http://www.w3.org/ns/hydra/context.jsonld",
>>>    "@id": "http://example.com/search",
>>>    "hyrda:operation":
>>>      {
>>>        "@type": "Search",
>>>        "method": "POST"
>>>        "expects" : "#SearchRequest"
>>>      }
>>> }
>>>
>>> To the uninitiated, this might suggest that we are subclassing POST and adding additional semantics to it, especially if we include return types and status codes.
>> I don't see any subclassing here. My mental model is rather a layered approach, like in the ISO/OSI model [1] model for interconnection:
>> On layer n we have HTTP with its well defined methods.
> Fair enough, subclassing is probably the wrong term here. The “@type” value of “Search” really doesn’t add any value to the operation.
>
>> On layer n + 1 we have an operation specified by the @type which is
>> in-turn defined in a vocab using the incredibly advanced semweb standards we have at our hands.
>> The operation is utilizing the capabilities of layer n - 1 (HTTP POST) but does not change its semantic.
> It changes how application developers deal with things. I worked a guy who was very excited about RDF and OWL and also had penchant for ORM tools. He found the old Sesame Elmo framework for Java and it’s Ontology compiler. IIRC, it leveraged domain and range to map ontologies to Java. This is rarely ideal and he ended up changing the data models so that it would suite his Java domain objects. You’d then end up with ontologies that did things like:
>
> dc:creator rdfs:range foaf:Person .
>
> While his Java domain objects looked like he wanted, it had a very interesting effect on inferencing. And by interesting, FUBAR'd! :) Creating a data model that generated bad inferences in relation to hydra:Operation may seem like a bit of a stretch. A lot of developers coming from Java or .NET already have a mental model that classes define their properties, and that’s not exactly true in RDF.

Actually I know someone very well who thought exactly like this and hit 
this trap :-D.

> Similarly, HTTP is not an RPC protocol. But developers who aren’t familiar with the HTTP model desperately want to make HTTP into an RPC model. If we describe Hydra operations like this, it’s very easy for someone to build tools that abuses HTTP in a similar way my former colleague abused the data model to get his Java objects more Java-ish. I’d like to see Hydra get these things right out of the gate so such behaviors are difficult to achieve.

I'm with you but as I pointed out thoroughly here [1], I think we cannot 
achieve this by
merely naming properties awkwardly. What you describe is mounted so 
deeply in developer's
habits that they must learn about RDFs basic concepts.

[1] http://lists.w3.org/Archives/Public/public-hydra/2014Feb/0102.html

>
> The @type of “Search” offers less value than the resource defined in the “expects” property. It’s here when’re it’s telling me how to format the message to the server. The operation subclass doesn’t do much in helping me achieve that. The majority of request formatting is expressed in #SearchRequest and not the #Search @type.

Hmm, for generic modelling of operations (or say forms because that 
would be the analogy in HTML)
I think you are right -- in that case I don't care about the @type.
But what If a client is specifically interested in a search operation of 
a Web resource.
In that case he might look for a well established operation like 
http://some.vocab.ns/Search
and inspect how to format a request message in the second place.
Use-case: A generic client could use this information to present the 
user a search input when
he browses a resource based on the existence of a search operation.

>
>> Now we cannot expect that intermediaries like proxies are smart enough to resolve the meaning of operations
>> and adapt correspondingly (although theoretically they could). More likely they will go through the same evolution
>> as firewalls and load balancers did. When they became available, they started caring only about layer 3
>> but meanwhile they work on layer 7. With well established operations, they can be taught how to react on them.
> Do you mean Hydra Operations?
>

Yes.

>> Today's intermediaries which only understand HTTP are dump from that perspective and that's ok
>> because this is in accordance with the OSI-Model: Communication partners exclusively communicate with
>> their counterpart on the same layer.
>>
>> I get the impression that some people desperately want to make those intermediaries smarter than they
>> are only because we use HTTP. But no matter how we format our messages and what concepts we introduce
>> in hydra they won't get any smarter.
> Agreed. I’d much rather work under the assumption that these pieces will remain as intelligent as the are today. It’d be years before intermediaries can become Hyrda-aware.

Definitely. I also think that the gains over time will be harder to 
achieve or take longer.
But this is natural as the whole semweb stuff is much more complex than 
the groundwork it is built upon.

>> [1] http://en.wikipedia.org/wiki/OSI_model
>>
>>
>> Thomas
>>
> +-----------------------------------------------+
>      Ryan J. McDonough
>      http://damnhandy.com
>      http://twitter.com/damnhandy

Received on Sunday, 16 February 2014 16:27:31 UTC