[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ETags and concurrency control
On Fri, Apr 25, 2008 at 8:19 AM, Pablo Castro
<Pablo.Castro@xxxxxxxxxxxxx> wrote:
> ETags in headers versus body: whenever we return a resource that represents a single underlying entity, if the entity has ETag-annotated properties we include an ETag response header. However, there are times where a URL points to a resource that's a list of other resources/entities (e.g. /Customers(123)/SalesOrders returns a feed with an entry for each sales-order resource for a given customer). In those cases returning an ETag in the header wouldn't help a client that will need to update a single one of those entries later on. So we include the ETag for each entry in an attribute in the entry element. I wonder if there is prior art for this...
AtomPub (Section 10) AFAIK, requires client NOT to assume a collection
feed contains full-representation entries. So, even if client
retrieves a feed of SalesOrder entries, client still need to retrieve
individual entry separately for editing purpose (therefore, it will
get entry's ETag HTTP header). As a result, embedded entry's ETag lost
its purpose.
A workaround discussed in [1] is to explicitly label collection feed
as 'full-content' feed, and require clients to check against the label
every time before it can assume the feed is full-content. For Astoria
use case, is it worth to workaround AtomPub's section 10 requirement
with two new extensions (full-content label + embedded entry etag)?
[1] http://www.imc.org/atom-protocol/mail-archive/msg10630.html
--
Teo Hui Ming