Hydra scope

I've spent the past day looking into Hydra and am very impressed with it and the JSON-LD movement.

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.
2. Complex, custom state transitions (not CRUD). State transitions are driven by use cases rather than data relationships.
3. Links for possible state transitions need to be dynamic, meaning the server decides which "next" transitions are appropriate with each server response.

>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.
2. Hydra works really well where there are common protocol semantics with differing data types.
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. :(

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).

Cheers,

Chris Chapman
Pentandra
@cd_chapman (twitter)

Received on Thursday, 1 May 2014 15:44:00 UTC