Using Hydra in non linked data ReST services

Hi

My name is Karol Szczepański and I've recently joined the Hydra community,
but I've got already some experiences with using it in real life.

These experiences are around describing linked data compliant ReST service
where client-server bi-directional communication was utilizing
RDF serializations (usually JSON-LD).

Recently, unhappy with how frameworks available for programmers exposes
ReST services, I've started thinking and working on something that would
allow programmers build ReST services more easy and by ReST I mean real
ReST where a common ground for both client and server is HTTP protocol and
not a blackbox named JavaScript (or JSON to be specific) wrapped around few
HTTP features (like verbs).

My thoughts came quickly to Hydra as the framework for describing the ReST
services, which rises few questions.

First of all, the Hydra spec mentions about linked-data services.
Unfortunately, this paradigm seems to be at the beginning of it's path and
still plenty of services are not RDF aware. This rises a question whether
is it considered to have Hydra capable of describing these services as
well. With the current state I find it quite difficult to express details
like media types allowed by operations.
This actually might be useful for RDF aware services where it is required
to send both RDF and binary blob. I've used the file API in latest
JavaScript specs to transform files into an xsd:base64Binary, but that felt
unnatural and multipart media type seemed a better approach.

It seems also difficult to get the client know i.e. when it can send a
single object/RDF statement, multiple ones or list of them. From RDF point
of view it is OK to have i.e. multiple statements with same predicate, but
probably most of you won't like to see rdf:List of rdf:Lists of rdf:Lists
instead, and these are pretty valid from the RDF point of view.

What are your thoughs on this matter, as I think it might be an interesting
feature of Hydra to describe both linked data and classic services alike.

Karol