Re: Hydra Design Goals: How important is RDF?

Hi Martynas

I'me aware of what you point at. I'm just open to a situation when a
response is not an RDF.

Imagine a situation when a REST API can i.e. accept a file for upload. How
would you express that? You cannot pass that as a hypermedia control as
there is no way of injecting this into a response that is i.e. binary.
You'll have to use an API documentation in advance to discover this. Other
thing that Hydra is not ready for such a situation and transforming a file
into a Base64 encoded value in RDF is not an option, believe me.

Another case - you can download a resource that is described in RDF, i.e. an
image in a desired format rescaled and transformed.
You might want to express this with an API documented templated link so the
client can provide all the supported options for the end user in advance
rather than to explore it on the fly either with hypermedia controls or
content negotiation. Alternative would end up with a response of content
type of multipart/mixed with both binary and RDF payload - while still
compliant with HTTP, it's not what developers and clients expects to
receive.

These are the cases I'm aware of. These are the cases that are frequent. And
let's be honest - while I'd love to see that, RDF is not popular way of
communicating with servers and there will always be a world outside this
scope and I'd like to cover these as well with a unified spec which I hope
Hydra will become in future.

Regards

Karol

Received on Friday, 2 October 2015 06:53:17 UTC