- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Thu, 30 Oct 2014 14:16:22 +0100
- To: Ruben Verborgh <ruben.verborgh@ugent.be>
- Cc: public-hydra@w3.org
- Message-ID: <CAKaEYhLKZx_AULzd0Mu+0QKaMSR7oHpAzvQ7Jc7wQY=DMczXFQ@mail.gmail.com>
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. > > > 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 13:16:50 UTC