Re: Some Thoughts on Hydra Core

On Wed, Oct 2, 2013 at 3:02 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> 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?

>
>
>> In a nutshell, POST doesn't alway imply create.
>
> Right, POST has no semantics at all. It's kind of a catch-all operation.
> Thus Hydra allows you to describe you the concrete semantics by means of
> (specialized) operations.
>
>
>> 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.

>
>> Another question is around how the Hydra vocabulary is to be used by
>> clients. It appears that this is all about runtime discovery and the
>> intent the intent is not compile time like WSDL or WADL?
>
> Exactly. Runtime discovery and adaptation works extremely well on the human
> web. IMO there are two reasons for that: a) there exist are extremely
> powerful clients (browsers) and b) there are quite clever agents controlling
> them (humans) :-P

Ah yes, the elusive "REST" client driven by machines ;)

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

>
>
>
> Cheers,
> Markus
>
>
> [1] https://github.com/HydraCG/Specifications/issues/11
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>



-- 
Ryan J. McDonough
http://www.damnhandy.com

Received on Thursday, 3 October 2013 02:38:32 UTC