Re: Inheritance / composition of term definitions

Hi

>>> No one prevents you from using the "other dimensions" of an IRI such as 
>>> the
>>> query string to differentiate here.
>>> For example to interact with the meta data part of a resource, you can 
>>> just
>>> have a ?meta in the URL.
>>> That's still restful as a different IRI can point to a completely 
>>> different
>>> resource, even if the difference is only in the query string.
>Yeah, how the URL looks like doesn't matter... in fact it shouldn't matter.
Indeed

>> I'd disagree - it needs a client to know something extra.
>Apart from the URL, what would it need to know that it wouldn't need to 
>know otherwise?
Well, this Url points to a resource that has some special meaning about 
other resource - in this case some meta data. How it is different from RPC 
and SOAP over HTTP? There you had some "resources" that had "special" 
meaning - some of them returned some meta data, some had different 
functionality.

>> I'd go with something that's a common ground for both client and server -
>> HTTP feature.
>> Meaybe a verb (i.e. OPTIONS - only drawback is that responses are not
>> cacheable), a specific acceptable content type or a request Link header 
>> with
>> some specific rel, i.e. meta.
>That's much, much more complicated to communicate to the client than just 
>pointing to a separate resource.
But still I'd believe this is more ReSTfulish that having special meanining 
resources.

>> I think an extra query string parameter is far from what ReST presents.
>> Optionally, you could indeed have that query string parameter, but this
>> should be additionally described with some hypermedia controls achieveing
>> both ReST and HATOAS simultanously.
>Of course.
This is still compliant with above suggestions - only difference is that the 
common ground of HTTP is extended with Hydra vocab.

>> In general, we've touched a matter of having data and 
>> meta-data/hypermedia
>> controls mixed in several discussions now. I personally prefer to push 
>> that
>> out of the data i.e. to headers or separate request or separate RDF 
>> graph. I
>> believe Hydra spec is silent in this area.
>I'm not a big fan of separating it.
Various cases would benefit from various approaches thus I'm not a believer 
here - being pragmatic is best.

Regards

Karol

Received on Saturday, 28 November 2015 20:35:45 UTC