Re: REST: Typed resources

Well, precisely, but Hydra does exactly the opposite when discovering supported operations for a given supported class. Th client looks up the type x:Page in ApiDocumentation and finds what operations are available for the resource itself and the x:next, x:prev links.

I'm playing devil's advocate here. I never realized there is something wrong with this approach until I've read the article below. In the end the supported class/properties are a way to define hypermedia controls outside the representation itself. Typed resource is a crucial bit in binding the documentation with actual data.

In a sense it is RDF-agnostic. One could even use Hydra as-is without being aware of RDF at all. Or implement a similar media type, where resource type is used to determine the link semantics. 

December 18 2015 4:22 PM, "Martynas Jusevičius" <martynas@graphity.org> wrote: 
> I think in RDF terms it means that when the client has to handle a
> response such as
> 
> <?page=2> a x:Page ;
> x:next <?page=3> ;
> x:prev <?page=1> .
> 
> it should rely on the properties (relations) such as x:next/x:prev for
> processing instead of types such as x:Page.
> 
> On Fri, Dec 18, 2015 at 3:58 PM, Tomasz Pluskiewicz <tomasz@t-code.pl> wrote:
> 
>> Hi Hydranians,
>> 
>> I've been reading a lot about broadly understood hypermedia APIs and I've come across the classic
>> Roy Fielding's post REST APIs must be hypertext-driven [1]. In that post Mr Fielding brings up a
>> number of points that I agree with and generally think should be obvious for a person who
>> understands REST. Among those is one that I'm don't really tie in with especially in the context
> of
>> RDF and Hydra:
>> 
>> A REST API should never have “typed” resources that are significant to the client. Specification
>> authors may use resource types for describing server implementation behind the interface, but
> those
>> types must be irrelevant and invisible to the client. The only types that are significant to a
>> client are the current representation’s media type and standardized relation names.
>> 
>> I've already expressed my dislike for the emphasis put on Media Types on this list. I consider
> RDF
>> the missing link in providing metadata and semantics. It seems to me that media types are a dead
>> end, because unless a server wants to provide resources in very different representations such as
>> hypermedia, vcard, image or audio it's fine. But with each individual server serving a different
>> hypermedia type, not to mention any possible vnd.*? How would that work? Let the client receive a
>> representation with media type vnd.my-cool-type+json;type=Person. Without knowledge of the
>> parameter's meaning and vendor extension it has to fall back to plain JSON. If it has a weird
>> document structure like HAL, SIREN or Collection+JSON does it's pretty much useless.
>> 
>> I see the motivation here. First, the client should not have to parse the representation if the
>> media type it does not understand. Also there is the assumption that such "typed resource" would
>> expose server's implementation details, ie. class name. However with RDF type type doesn't really
>> work this way. It doesn't have to match any server side storage or implementation class but
> rather
>> serve as metadata with Hydra being it's a hypermedia extension.
>> 
>> I'm not sure what to make of it. Hove any of you had similar reflections? If so, and you agree
> with
>> Roy Fielding, maybe it makes sense to extend the default media type with resource type, so that
>> clients don't have to rely on the representation too much?
>> 
>> Thanks,
>> Tom
>> 
>> [1]: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Received on Friday, 18 December 2015 15:42:16 UTC