- From: László Lajos Jánszky <laszlo.janszky@gmail.com>
- Date: Tue, 23 Sep 2014 16:23:58 +0200
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: "public-hydra@w3.org" <public-hydra@w3.org>
> Correct. But you also don't know if the embedded representation is "complete" or not. Ofc. but I don't think it is necessary the client to know that information. If the server gets a PUT request with missing parameters, then it is probably the sign of a poorly designed link and not a poorly designed client. You can give the full parameter list and use PUT, just by any other links... Ohh. btw I have questions about links too, I'll create a new thread. 2014-09-21 22:23 GMT+02:00 Markus Lanthaler <markus.lanthaler@gmx.net>: > On 20 Sep 2014 at 01:31, László Lajos Jánszky wrote: >>> Can you think of an use case that can't be addressed by these mechanisms? >> >> HTTP headers typically break if you want to describe an embedded >> resource with them. So for example if you represent an embedded >> resource along with a PUT or PATCH link, then the etag header is >> related to the original resource and not to the embedded resource. So > > Correct. But you also don't know if the embedded representation is "complete" or not. > > >> you cannot extract the etag of the embedded resource from the headers, >> you have to send it in the message body. And since it is in the >> message body, it has to be annotated with metadata. >> >> Just a short example using a human readable format: >> >> { >> users: [ >> { >> name: "John", >> etag: "...", >> links: [ >> { >> href: "http://example.com/users/1", >> rel: "http://example.com/rels#update", >> method: "PATCH", >> fields: ["name", "etag"], >> title: "update single embedded resource" >> } >> ] >> }//, >> //... >> ], >> links: [ >> { >> href: "http://example.com/users", >> rel: "http://example.com/rels#bulk-update", >> method: "PATCH", >> fields: {users: ["name", "etag"]}, >> title: "update multiple embedded resources" >> } >> ] >> } >> >> Is it possible to send these etags in request and response headers. >> Afaik the server can send only a single etag header by each response, >> and the client can send only a single etag header by each request. But >> maybe I am wrong... > > No, that's correct. I worked on a different project a couple of years ago that had support for "embedded ETags". It sounded nice in theory, but in practice it didn't make much difference. If a resource is critical enough to require conditional requests, it should be worth the extra request to get its authoritative representation. > > > -- > Markus Lanthaler > @markuslanthaler > >
Received on Tuesday, 23 September 2014 14:24:26 UTC