RE: Hydra scope

Hy Chris,

On Thursday, May 01, 2014 9:54 AM, Chris Chapman wrote:
> I've spent the past day looking into Hydra and am very impressed with it and the JSON-LD
> movement.

Great. Thanks. In that case, you should probably join our community group at

    http://www.w3.org/community/hydra/

:-) You don't have to be a W3C member of anything, but you need to get a (free) W3C account at [1] if you don't have one yet.


> I am trying to determine whether Hydra would be a good fit for a project, and I would love
> some feedback.
> 
> My requirements
> 1. Combine the best of linked data and REST (self-describing messages), ideally using
> JSON-LD.

This is exactly what we are trying to do.


> 2. Complex, custom state transitions (not CRUD). State transitions are driven by use cases
> rather than data relationships.

Could you please explain in a bit more detail what you mean by the second sentence?


> 3. Links for possible state transitions need to be dynamic, meaning the server decides which
> "next" transitions are appropriate with each server response.

OK. That's trivial. You just include or exclude those links in your responses.


> >From what I understand of Hydra so far (please correct me if I'm off base):
> 1. Hydra is geared primarily towards hypermedia CRUD APIs driven by data relationships.

Nope. It works for completely arbitrary operations. The predefined CRUD operations are just there as examples, in most cases you would either want to define your own or, even better, use existing ones such as the ones from Schema.org's Action subtree [2]. This will be clarified in a future version of the spec.


> 2. Hydra works really well where there are common protocol semantics with differing data
> types.

I'm afraid I don't understand what you mean by this.


> 3. All possible protocol and application semantics (operations, etc.) are known by the client
> ahead of time (in the app's context). The hydra:Class determines which of the operations are
> deemed appropriate in the current situation. For CRUD would work really well, but for a
> more complicated non-CRUD API this would fall apart, requiring the client to understand
> business rules to make appropriate decisions about transitions, potentially doing away with
> HATEOAS. :(

The client obviously needs to "understand" the application domain (products, orders, etc.) and Hydra (operations, links, perhaps also collections and templated links). Operations can not only be bound to classes but also to links, i.e., properties or link relations if you want. Furthermore, you can include them directly into responses which would be more or less the equivalent of including forms in an HTML document. Hydra was specifically created for hypermedia-driven Web APIs. So, if you think we violate the HATEOAS constraint, you should tell us as that would be a serious issue.


> At first glance, it doesn't seem that Hydra would be a good fit (or am I seeing things
> wrong?). If not, do you feel that this would be within the scope of a Hydra extension or
> would it fit better in a separate project (or has work been done in this area by someone
> already? I would rather collaborate than duplicate efforts).

I think you got it partly wrong which without doubt has to do with the current state of the documentation. From the limited information you provided about your project, I think Hydra would be a great fit. Please don't hesitate to ask further questions or propose extensions etc. Let's see where we can take this together and welcome on board :-)


Cheers,
Markus


[1] https://www.w3.org/accounts/request
[2] http://schema.org/Action


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 1 May 2014 21:55:53 UTC