Re: hydra and void

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

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

Best,

Ruben

Received on Thursday, 30 October 2014 12:58:39 UTC