RE: Representing HTTP forms in Hydra

On Thursday, April 10, 2014 1:05 PM, Eric Moritz wrote:
> The long and short of it is we have HTML clients that can only send
> application/x-www-form-urlencoded request to the service. Rather than
> proxy the request through the web application I'd rather have the HTML
> client send the data directly to the service.

Fair enough


> I need to be able to map form fields to RDF properties so we don't
> lose the semantics.  We have that with IriTemplates but not with
> request payloads.
> 
> The reason we need this is less about describing legacy APIs and more
> able enabling server-side web apps (think PHP, Django, Rails, etc) to
> construct HTML clients with just HTML for graceful degradation without
> tunneling the request through the server-side app.

OK... so this is really about human-facing HTML interfaces then, right?


> Perhaps this is not the responsibility of Hydra and a separate HTML
> form to RDF property vocabulary is needed.  I'll leave that to the
> community it decide. 
> Does that help?

The question is how does the client use the Hydra description. If I
understand you correctly, it doesn't use them at all (at least in the
fallback mode). Is that correct?


> Thanks,
> Eric Moritz.
>
> On Apr 10, 2014 5:58 AM, "Markus Lanthaler" wrote:
> >
> > Hi Eric,
> >
> > Sorry for the delay... unfortunately I have to say that quite often
recently
> > :-(
> >
> > On Monday, March 31, 2014 5:30 PM, Eric Moritz wrote:
> > > Hi I would like to describe an application/x-www/form-urlencoded form
> > > much like I can for IRI templates.  What I have been using is the
> > > hydra:supportedProperty property on a  hydra:Class.
> > >
> > > For instance this is my form being POSTed to the service:
> > >
> > >
> > > cookieService:CookiesForm
> > >      rdfs:type hydra:Class ;
> > >      rdfs:comment "The cookie form can be submitted with "
> > >
> > >      hydra:supportedProperty [
> > >          rdfs:type hydra:SupportedProperty
> > >          rdfs:comment "The _method hack for non-RESTful clients"
> > >          hydra:property cookieService:method
> > >          hydra:variable "_method"
> > >      ] ;
> > >
> > >      hydra:supportedProperty [
> > >            rdfs:type hydra:SupportedProperty ;
> > >            rdfs:comment "URL to redirect to" ;
> > >            hydra:property http:location ;
> > >            hydra:variable "location"
> > >      ] ;
> > >
> > >      hydra:supportedProperty [
> > >            rdfs:type hydra:SupportedProperty ;
> > >            rdfs:comment "The content type to return; supported content
> > >              types are 'text/html' and 'application/json'" ;
> > >            hydra:property http:accept ;
> > >            hydra:variable "accept"
> > >      ] .
> > >
> > > I noticed that hydra:variable has a domain of hydra:IriTemplateMapping
> > > which turns the range of the hydra:supportedProperty into a
> > > hydra:IriTemplateMapping; which it is not.
> >
> > Right.. we could however, introduce something like hydra:parameterName..
We'd
> > also need to describe something on the operation level to indicate that
the
> > server expects a application/x-www-form-urlencoded string instead of
JSON-LD
> > payload.
> >
> >
> > > Our clients are a mix of HTML, JSON and Linked Data clients so I would
> > > like to be able to describe how HTML clients can be rendered using
> > > Hydra.
> >
> > The alternative is to dynamically construct a JSON-LD payload when the
form
> > is submitted. That's basically what I do in the Hydra console. Obviously
> > that doesn't help if your server doesn't understand JSON-LD at all
(e.g.,
> > because it is a legacy API). Is that the reason why you want urlencoded
> > forms?
> >
> >
> > > Is it possible to describe how to construct a application/x-www/form-
> > > urlencoded using Hydra like we can for an Iri Template?
> >
> > Currently it isn't but if people ask for it, we could certainly add it.
> > Could you please elaborate a bit on why you need it and why you don't
want
> > to send JSON-LD payloads?
> >
> >
> > Thanks,
> > Markus
> >
> >
> >
> > --
> > Markus Lanthaler
> > @markuslanthaler
> >

Received on Tuesday, 15 April 2014 20:12:41 UTC