RE: Some Thoughts on Hydra Core

On Thursday, October 03, 2013 4:38 AM, Ryan McDonough wrote:
> On Wed, Oct 2, 2013 at 3:02 PM, Markus Lanthaler wrote:
> > On Wednesday, October 02, 2013 4:09 PM, Ryan J. McDonough
> >> I was looking at this as well and I had some questions about the
> >> different specializations of hydra:Operation. I see the can
> >> hydra:Operation as a means to fill the role of Link relations I have
> >> been talking about in other threads, On the other hand, I can see this
> >> getting unwieldy, especially when it comes to POST operations.
> >
> > Unwieldy in which sense?
> 
> When I wrote this, I was thinking about the potential for an explosion
> of hydra:Operation subclasses for HTTP POST methods and the likelihood
> that we'd see multiple, redundant subclasses. But then again, if you
> frame hyrda:Operations in the context of link relations, maybe it
> wouldn't be so bad? Assuming of course I'm not suffering from cranial
> rectal inversion in thinking that hyrda:Opertion and link relations
> are similar in their functionality?

I hope the other mail I just sent clarifies that. Have you seen that schema.org recently introduced Actions [1]? They also already defined quite a few specialized actions [2]. That's exactly what I had in mind with Hydra.


[1] http://schema.org/Action
[2] http://schema.org/docs/full.html


> >> My question is really about
> >> having CreateResourceOperation or RetrieveResourceOperation being a
> >> part of Hydra core. It seems like these might be better served as
> >> examples rather than part of the core vocabulary.
> >
> > I agree. I just fear that it than becomes very difficult to explain
> > Operations without making it looking too complex. Nevertheless, I've
> created
> > ISSUE-11 [1] for this as we should definitely discuss this further.
> 
> I think the answer here could be in the form of a reference app.
> Something akin to the Java EE PetStore or Microsoft's Northwind
> project examples. It could also be a cook book that demonstrates how
> to solve common problems. This is where you demonstrate how the
> subclassing works. No doubt, this is a huge effort but I think it's be
> necessary to illustrate how it things could get done.

That's something I had on my to do list for way too long already. Maybe we can build something together as a group!? Who would be interested?


> > Hydra is a modest attempt to enable the creation of generic clients and to
> > provide enough semantics to (semi-)automate their operation. I believe the
> > Hydra console nicely illustrates that it is possible to create completely
> > generic API clients for Hydra-powered APIs. Unfortunately, I haven't been
> > able to demonstrate the second aspect just as well yet... but I'm sure we'll
> > get there!
> 
> Good, I was hoping to hear this wouldn't end up like another WADL. Are
> there plans or thoughts around a Hydra API similar to that of JSON-LD
> API? I believe that such APIs, or even a loosely defined programming
> model, help immensely. I know it's still early in the game, but just
> throwing that out there.

Definitely. I've started working on a primitive API for accessing such APIs almost a year ago but unfortunately didn't find the time build something worth sharing. I started with the low hanging fruit, i.e., build an API which works similar to a browser. Something like

  get(/api-entrypoint)
    ->follow(issues)
    ->do(CreateResourceOperation, myissue)
    ->get(@id)

I've also been tinkering with describing the desired goal in a bit more abstract way. For example something like

  get(/api-entrypoint)
    ->tryTo(CreateResourceOperation, myissue)

The client then analyzes the API description and would try to find its way to a resource which supports a CreateResourceOperation that accepts an Issue.

What do you think?


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 3 October 2013 20:25:31 UTC