- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Sun, 21 Sep 2014 22:23:37 +0200
- To: <public-hydra@w3.org>
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 Sunday, 21 September 2014 20:24:06 UTC