Re: hydra and void

> On Oct 30, 2014, at 6:16 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
> 
> 
> On 30 October 2014 13:58, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> Hi Melvin,
> 
> > Just about using the right tool for the right job.  In an ideal world everything would be 5 star linked data, and (1) would be dominant.  But we have some work to go before that is true.
> 
> Sure. But if you're looking to design an API, the easy way would be to add the link.
> 
> > Got it, trying to work out how it would look.
> >
> > My use case is:
> >
> > <user> <predicate> <payment_processor> .
> 
> So let me interpret that.
> You want to make sure that users can pay?
> 
> So I'll assume that they have some shopping cart then.
> Or maybe just an article they want to buy.
> 
> Remember that Hydra is for resource-oriented APIs,
> so “payment_processor” would probably not fit into that category.
> Rather, it could be something like:
> 
> - the status of this shopping cart can go from "unpaid" to "paid";
> - or: this shopping cart has the following payment form
> 
> This could translate to a relation such as:
> </shopping-cart/2645> <hasPaymentForm> </shopping-cart/2645/payment>.
> 
> We haven't solved the "what predicate" question yet;
> I'm just trying to figure out how things are modelled.
> (But note that you likely would not have a "user" as subject.)
> 
> Thanks for the response, apologies for not providing a context.
> 
> By payment processor, I mean more like a banking facility.  So the API provides:
> 
> Read functions:
> - Get balance (based on a URI)
> - Get transaction history (based on a URI)
> 
> Write functions
> - Transfer to another URI
> - Withdraw to another wallet (using crypto currency addresses)
> - Deposit funds
> 
> Both the read and write functions ideally will occur using self describing RDF.  So I think adding hydra here would be a nice way to document such interfaces.
> 
> My client side app will authenticate a user, and from there it need to know, 'Which service does this user hold a balance with' ie 'Where can I find the banking facilities for this user'.
> 
> From that triple (or triples) it needs to work out where are the APIs for balance, deposit etc.  Later on there will be more APIs such as trust scores and reputation for various URIs
> 
> So, I wonder can I say:
> 
> <:user>  <:hasProvider> <http://example.org>
> 
> then
> 
> <http://example.org> <:hasAPIDocs> <URL> .
> 
> Or something like.  My use case it to integrate payments into the world of linked data, if that makes any sense.


Also, note the Link header which should be returned by a server implementing Hydra as described in 4.3: http://www.hydra-cg.com/spec/latest/core/#discovering-a-hydra-powered-web-api

[[[
EXAMPLE 11: Discovering Hydra API documentation documents
HEAD / HTTP/1.1
Host: www.example.com

====================================

HTTP/1.1 200 OK
...
Content-Type: text/html; charset=utf-8

Link: <http://api.example.com/doc/>; rel="http://www.w3.org/ns/hydra/core#apiDocumentation"
]]]

Go to any page of the site, see the Link header response, and load the associated Hydra API document to understand how to interact with this, or other resources.

Gregg

> 
> > Payment Processor I think would probably be the root domain, meaning more follow your nose to the API.
> 
> Yeah, but not that the resource that you retrieve *is* already part of the API.
> So once you are reading the above predicate, you're already in it.
> 
> > Still slightly unsure what triples would work best for discovery of *where* the APIs live, but I think I'm making progress!
> 
> If a client is reading a resource, it is already inside of the API.
> 
> So, if I've understood correctly, there's two parts
> 
> 1. The APIs
> 2. The hydra API description docs
> 
> If I find my way to (2), then the machine can work out where (1) is?
>  
> 
> Best,
> 
> Ruben
>

Received on Thursday, 30 October 2014 16:53:23 UTC