RE: Let's get started

On Friday, June 28, 2013 5:35 PM, Ioseb Dzmanashvili wrote:
>> It could also be the current version of the spec assumes too much
>> Linked Data knowledge. Maybe that's one of the first things we could
>> try to address (if needed)!? Willing to do a quick review and see if
>> something assumes too much?
>
> I do not think something assumes too much, its just new for me. In my
> opinion format itself is quite clean and minimalistic.

Good to hear


>> Just to clarify it, by "to generate client-side and server-side
>> validation code" I didn't mean code generation in the classic sense but
>> to be able to write a generic validator that knows how to interpret
>> descriptions in order to validate specific properties etc.
> 
> This sounds reasonable. I'm not sure how these feet in linked data
> philosophy, but three approaches come to mind:
> 
> 1. Use regexs to specify validation rules, but i do not think its
> reasonable as far as there are several non compatible regex processing
> engines and it is not practical to specify which engine needs to be
> used to process regexs;

Yeah, that's always problematic. The simplest thing would be to just pick a widely supported one. Otherwise, we could allow multiple and define a datatype for each to be able to distinguish them.


> 2. Use specific types in property descriptions i.e. number, string,
> email, URI etc… in this case some types can be described with ABNF or
> existing RFCs indicated directly(later creates direct dependencies to
> other specs though); and

That's currently my preferred choice. A consumer has to have at least some degree of understanding of the data anyway.


> 3. Use property type registry and use URIs to specify property type,
> this way validation rules will be deferred to type description spec.

Not sure I understand you correctly here. What's the difference to the previous point? Just that the type is specified using a URI? Generally speaking, in Linked Data everything is defined using a URI. 


> > > > - "single-click actions", i.e., operations which do not require any
> > > > use input, such as a "like". Typically, I consider such things an
> > > > anti-pattern in terms of a RESTful architecture but sometimes they
> > > > are really handy
> > >
> > > +1 even though i was highly criticised on other mailing list for my
> > > attempt to "standardise" single-click actions[1] i'm still interested
> > > in this topic and hope to find non anti-pattern ways to use this
> > > concept .
> >
> > I know, I was one of them :-) Let's see if we can come up with
> > something we are equally (un)happy together.
>
> I'm looking forward to try :-)

The way I would currently model that in Hydra is to define an Operation that conveys the semantics of the action (in JSON-LD omitting the context):

{
  "@id": "#LikeOperation",
  "@type": "hydra:Operation",
  "title": "Like the resource"
}

and then either define a resource type for things that are "likeable" using the URL of the resource or a property if a different URL has to be used. Let's create a property "like":

{
  "@id": "#like",
  "@type": "hydra:Link",
  "title": "The target of this link can be used to like the resource",
  "supportedOperations": {
    "@type": "#LikeOperation",
    "title": "Like the resource",
    "method": "POST",
    "expects": null
  }
}

Then, finally you can use the new "like" property in your resources like so:

{
  "@id": "/blog-post",
  "title": "Awesome blog post",
  "like": "/blog-post/like"
}


It may look overly complicated to create a separate operation type that consists of just a title (in this example). The reason why I did that is because I wanted to separate the semantics of an operation from the details, such as the HTTP method to use, needed to invoke an operation. This allows you to reuse the same operation in different contexts.

What do you think about this approach? Do you see a way to simplify it?



--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 3 July 2013 09:56:59 UTC