Re: My opinion about hydra vocabulary

Do you intend to describe every REST service with Hydra, or just a specific implementation of REST services?

For example should a Hydra REST service accept all of these requests or just a single one of them?

 - PATCH "/users/123" {firstName: "John", secondName: "Smith"}
 - PATCH "/users/123" {name: "John Smith"}
 - PATCH "/users/123" {givenName: "John", familyName: "Smith"}
 - PATCH "/users/123" {name: {first: "John", second: "Smith"}}

 

 

2014-06-03 20:39 GMT+02:00 Markus Lanthaler <markus.lanthaler@gmx.net <mailto:markus.lanthaler@gmx.net> >:

On Tuesday, May 27, 2014 3:18 AM, László Lajos Jánszky wrote:
> If I am correct with your vocab you cannot describe asymmetric
> representations of the same resource or property, because it does not
> really describe the representation, but just the resource graph
> itself.

I don't know what you mean by "asymmetric representations" but you are right, Hydra (and RDF in general) don't describe the representation but the raw data or resource graph as you call it.



> For example by a password you can have a password input field,
> a password-again input field and a password-hash-abbr output field
> representing the same property.

Right, but that's a concern for a user interface and not for a Web API. Hydra doesn't describe at all how the user interface should look like. It just describes the data the server expects to carry out specific operations.



> Or by a birthday you can send the date
> in iso 8601, timestamp, yyyymmdd, etc... which are different
> representations of the same property. By resources you can have much

You can set the datatype of a property (using rdfs:range). In a Web API you typically just want one. If you want to indicate that you support multiple, you could use schema:rangeIncludes.



> more complex representations of the same resource, which can be
> different from each other either, for example their can contain
> different properties, different links, or have different structures,
> and so on... All of these are not part of the resource graph, just
> different representations of resource graph fragments. How do you
> intend to model this part of your REST API?

You can describe what properties are required to create a valid request. Do you need more than that? Do you need to know beforehand what properties the server returns in different places (entity page itself, entity included in collection, entity referenced by other entity, etc.)?


--
Markus Lanthaler
@markuslanthaler