- From: Karol Szczepański <karol.szczepanski@gmail.com>
- Date: Sun, 13 Mar 2016 22:59:29 +0100
- To: Asbjørn Ulsberg <asbjorn@ulsberg.no>
- Cc: <public-hydra@w3.org>, "Tomasz Pluskiewicz" <tomasz@t-code.pl>
Hi Asbjørn
>> PUT /blog/{id} - update the blog with a published state
>It’s nitpicking, but you can’t really update anything with PUT. You can
>only replace the entire resource.
>If you want to change the value of a single property and leave all other
>properties of the resource untouched, you’d need to use PATCH.
Well, in ReST, i'd expect a whole resourece, client modifies a property and
sends back the resource.
>> It would be also more approriate (in my opinion) to allow client to put
>> existing blog directly to either of the states with PUT - if the client
>> is instructed on how to build a valid Uri.
>> HTTP spec allows PUT to create a resource if the Uri is known.
>Besides having to know the URI before doing PUT, functionally PUT and POST
>are equivalent here, I’d say. Why does PUT make more sense than POST, in
>your opinion?
If client knew how to create a new Uri for PUT method, it could just use the
resource from previous POST/GET and send it with PUT directly to the new Uri
without the intermediate POST container, i.e.:
- POST /blog -> Location: /blog/whatever
- GET /blog/whatever -> resouce with operation that uses an IRI template
/blog/published/{id}, where id is mapped to a resouce's property - it would
end up with a new uri ...
- PUT /blog/published/whatever
Best
Karol
Received on Sunday, 13 March 2016 21:59:59 UTC