Re: Editing resources

I understand what you're saying. My question is about how a Hydra client
should behave when editing a resource. I want my version of the Hydra
Client to behave in a different way to the official Hydra client [1]. Sorry
if I didn't explain it very well before, I'll try to be clearer.

To reproduce the issue:

   1. go to the Hydra events demo [1] and click the 'Load' button
   2. notice that each member in the events collection only have "@id" and
   "@type" information (the member doesn't contain a full representation for
   the resource)
   3. click on the first event's "@id" attribute to open the Hydra
   operations dialog box
   4. select PUT from the drop down list
   5. notice that fields for 'name', 'description' and 'start_date' are
   blank, even though values are available for them (which you can confirm by
   doing a GET on the resource)

My question is - should the fields in the PUT form be blank? In my version
of the Hydra Client I would like the fields to be populated with the data
for the event (by automatically doing a GET request for the resource). I
think the fields should be populated because:

   1. a human user would want to see the current values to provide some
   context
   2. A user might want to correct a typo rather than retype every entry
   (possibly introducing more typos)
   3. a user might want to leave some values unchanged when they edit the
   resource
   4. a machine agent might use the Hydra Client to edit the data, for
   example you could write a machine agent to capitalise the first letter of
   every rdfs:label in the API across all resources. If the fields in the PUT
   request aren't populated with data then the agent wont work (this is a
   contrived example, my point is that we should consider non human users of
   the client as well as human users)

I hope that clarifies things, otherwise let me know.

Thanks,

Kev

[1]
http://www.markus-lanthaler.com/hydra/console/?url=http://www.markus-lanthaler.com/hydra/event-api/events/

On 2 November 2014 15:40, <tomasz@t-code.pl> wrote:

> Hi
>
> comments inline
>
> October 30 2014 11:35 AM, "Kev Kirkland" <kev@dataunity.org> wrote:
> > I've been looking at how to edit resources with Hydra.
> >
> > I don't think this has been implemented in the demos yet. For example if
> you go to the events list
> > demo [1] and choose the PUT operation for one of the events, the form's
> input boxes are blank
> > rather than having the current event's details filled in.
> >
> > I'm looking to put editing into my AngularJS Hydra client. To fill in
> the PUT form with the details
> > of the resource you are editing, do you do a GET request to the form's
> URL to get the
> > representation of the item you are editing then use it to populate the
> input boxes on the form? So
> > for the events demo would the sequence be:
> >
> > find an event to edit (e.g. /hydra/event-api/events/1)
> > choose the PUT operation for the event
> > do a GET request to fetch the resource's representation (e.g. GET
> hydra/event-api/events/1)
> >
>
> I don't understand this order. What does the first step mean? How do you
> "find an event to edit"?
>
> In general RESTful services work by first retrieving a resource
> representation and then following links or invoking actions. Each
> subsequent resource retrieved is your application state. That resource's
> representation together with some metadata (Hydra fulfills that role in our
> case) lets you decide what will be the next request.
>
> So, my point is that typically you would first get the resource and only
> then discover that a PUT is allowed. Otherwise you are making assumptions.
> Even if you knew the URI, you don't have enough explicit information
> required to act upon it.
>
> >
> > use the GET request's data to fill in the input boxes on the PUT form
> > submit the PUT request (with user's edits) to the url of the event (e.g.
> > /hydra/event-api/events/1)?
> >
> > Thanks,
> >
> > Kev
> >
> > [1]
> >
> http://www.markus-lanthaler.com/hydra/console/?url=http://www.markus-lanthaler.com/hydra/event-api/e
> > ents/
> >
> > --  www.dataunity.org twitter: @data_unity
>
>


-- 
www.dataunity.org
twitter: @data_unity