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

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. 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. 

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.

> 
> 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? 

> 
> 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. 

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