W3C home > Mailing lists > Public > public-hydra@w3.org > June 2014

RE: My opinion about hydra vocabulary

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Thu, 5 Jun 2014 23:26:55 +0200
To: <public-hydra@w3.org>
Cc: 'László Lajos Jánszky' <laszlo.janszky@gmail.com>
Message-ID: <019d01cf8104$e0f8d590$a2ea80b0$@gmx.net>
László, you keep forgetting to CC public-hydra@w3.org. This is important as otherwise only I will receive your messages. I've forwarded your message to the list but please remember to send it yourself in the future.

Also, please try to stick to text-only mails instead of sending HTML mails. This makes the archive at http://lists.w3.org/Archives/Public/public-hydra/ much easier to read and follow.

If you look at your latest message, you'll see what I mean:

More to your actual question below.

On Thursday, June 05, 2014 8:47 AM, László Lajos Jánszky wrote:
> > > 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"}}
> > 
> > How could I answer this question? I know nothing about the service.
> > Hydra just describes what can be done how. It doesn't prescribe what
> > must/must not be done.
> Okay, then I ask otherwise. Is it possible to have a Hydra REST API
> which can accept all of those PATCH requests and do the same operation
> using the request body?

Yes, you could do that if you would be fuzzy enough about the range, i.e., the value space, of name (it needs to support both a string and and a structured value). Furthermore, all parameters would have to be marked as optional. I just wonder why you might wanna do that? It just makes life for everyone much more complicated. In general, you should try to design an API so that the same thing can't be done in multiple ways.

Markus Lanthaler
Received on Thursday, 5 June 2014 21:27:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:53:59 UTC