CODEWITHSUNDEEP
resthttpsemantic-markupetag
AdamZ
AdamZ

Reputation: 2021

HTTP weak Etag example,

I've been trying to understand HTTP Etags and came up with an example usage. Am I correct with my thinking?

Lets say we have some RESTful API with custom link types. Some resource returns a XML data with links like this:

<link rel="http://my.api/relation_definition" url="http://my.api/resources/someId"/>

Note the custom rel definition that leads to some description of meaning of that link.

Now, if this rel description would provide a weak Etag. Programmers that create a client for my REST api could embed this etag in his/hers client. Since custom relation may mean some special behaviour of client app. Now the client app could check if link definition has;nt changed by querying with that weak etag. If it's the same, it is ok. If weak etag has changed that would mean that client may have to change/reconsider it's behaviour on these links and probably notify it's developer to take some actions.

I use weak etags instead of strong ones because I, as a provider of api could change the description of link more often, fix typos, add some examples etc, that does'nt change meaning. So I'd change weak etag of the description only if the meaning of these links is changed.

Am I correct in understanding purpose of weak etags?

Upvotes: 0

Views: 1466

Answers (1)

AndrewF
AndrewF

Reputation: 1906

It's most important to realize that changing the ETag, whether weak or strong, will cause the browser to request the asset anew. The only difference is how much the browser trusts the ETag when you DON'T change it.

For your use case of "some description of meaning of that link", it sounds like you're talking about a small document with static (or nearly static) content, so it doesn't really matter whether your ETag is marked as weak or strong because the browser probably isn't going to do anything special that could benefit from the guarantees of a strong ETag. API clients probably don't care about weak vs. strong ETags at all.

Where strong ETags come into play is for large downloads (software, videos, audio, etc.) where the browser might use range requests to download just part of the asset. A strong ETag means that the item is byte-for-byte identical, so it's okay to use chunks of the file that were downloaded previously. So for example, imagine resuming a big download that you started last week. If the ETag was the same but it was weak, the browser might decide to redownload the whole file, whereas a strong ETag might lead to resuming the existing download.

Again, for your case, don't even worry about it. If you're using a hash of the file, you're guaranteed the "byte-for-byte identical" semantics, so go ahead and call it strong, but either way should work the same for you. Again, API clients probably don't care about weak vs. strong ETags at all.

As for when you should change the ETag, unless you're making 100 changes a day, do go ahead and change it every time you make a change.

Upvotes: 3

Related Questions