ETags - What are the benefits

[Chris Fidao]

Regarding ETags in API's - 

I want to confirm the suspicion that I have that ETags (from a server point of view) main benefit are to save bandwidth.

It seems to me (from my reading) that you have to do the processing to generate an ETag on each request in order to compare to the one given by a client. 

This seems true even with cacheing involved (as a cache is simply a "quick" data-source, and you need to query a data-source to see if something has changed or not).

Thus it seems to me that ETags are a "scale feature" in which you save bandwidth over time, and thus cost savings (Esp if you're cloud-based and are charged by bandwidth).

Am I off base? In an API which queries a data-store (sql, nosql, etc) to get data, are there strategies for using ETags in a way to save data queries/computation?

Thanks

[Felipe Sere]

You can use them to do conditional GETs. Depending your application you won't have to actually do any peocessing (e.g if you use the revision in mySQL as etag and are able to query it). We use the etag to solve the lost update problem

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Gruß,
Felipe

[mca]

ETags are quite useful for handling optimistic concurrency checks for writes to existing resources.

http://www.w3.org/1999/04/Editing/

mca

+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

[Chris Fidao]

Thanks for your replies:

Conditional Get: If I understand, this is basically a way to say "if the resource has changed, send it, otherwise response with a 304" - However, you still need some sort of data-query to determine if the resource has changed (And you need all the relevant data at hand to compute a change and generate the etag to compare against the client provided etag - So this gets to my question of if this saves bandwidth over actual processing/querying time, in terms of performance gains.

I could envision where an etag is generated based on "last update date" of a specific resource (data table row), and so save time from potential complex-queries. However, descriptions of ETag's I've seen often talk of them as part of a "cacheing" mechanism, and that I believe is where my confusion on its benefit has come from.

Lost Update Problem: This seems to be where ETags shine then, as they provide a real, functional benefit (Altho not necessary a "cacheing" benefit).

Do these distinctions/questions I'm asking make sense?

[Glenn Block]

You don't necessarily have to do a database query with ETags. All you need is to have a collection of valid ETAGs for each resource, where the tags get invalidated whenever the resource changes.

ETags do cut down on bandwidth for sure, But with conditional updates it's more than that, it's addressing concurrency / preventing clients from overriding newer changes.

--