- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Thu, 3 Oct 2013 22:25:02 +0200
- To: "'Ryan McDonough'" <ryan@damnhandy.com>
- Cc: <public-hydra@w3.org>
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