Title: Why would ETags set to a MUST requirement if you already have the resource?
Tags: rest;http;http-headers;cache-control;etag
Question: Why would you set ETags to a "MUST requirement level"?
You obtains the resource before the ETags returned...
I'm working on a project where I am the client that sends HTTP requests to a server that returns an HTTP Cache-Control header with ETags to cache response (where in each addition request it gets compared to the If-None-Match header to determine if the data is stale and if a new request should be made). In my current project the ETags parameter is using the conditional GET architecture with the MUST requirement level as specified in RFC 2119.
MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
I don't understand the intent of using a conditional GETwith the MUST requirement level? From my understanding the MUST requirement is there to limit (is that right?) the resources provided to the client that makes the request, however the client (me in this case) already has the resources from the first request. Where I can continue obtaining the same resource (or a fresher resource if it gets updated) as much as I want with or without returning the If-None-Match and ETag header fields.
What would be the purpose of setting it to the MUST requirement level in this case if it's not limiting the resources returned, Aside from being able to cache and limiting the amount of requests to the server (Im asking from the client point of view, yes I know I can cache it but why the MUST requirement)? Isn't this only used for limiting resources?
So basically, doesn't it make this MUST requirement not a requirement if I can obtain the resources with or without it? Am I missing something here?
My Question is not asking the what and how Etags, Cache-Control, or If-None-Match headers work.
Thanks in advance, cheers!
Comment: The question is not clear to me, I think you should clarify. Conditional Get, using `If-Modified-Since` is used to validate the cache of the proxy servers, whereas the `ETag` and `If-None-Match` are used to validate the client cache. In a RESTful API, I would avoid proxy caches in most cases. Only leaving the client cache, and the gateway cache. But this is a policy that is set by the API provider, not the client. What's your API provider policy? what kind of `cache-control` headers is issuing?

Comment: I think everyone understands what "MUST" means. It would be preferable if you posted the whole context verbatim not from the keywords document but from the document pertaining to the Etags, and in what context "MUST" is used. You have not provided this information.

Here is the accepted answer: Why would ETags set to a MUST requirement if you already have the resource?
A client MUST use a conditional GET to reduce the data traffic.
Aside from being able to cache and limiting the amount of requests to the server
The number of requests stays the same, but the total number of data transferred changes.
Using ETags in if-none-matched GET requests (conditional GET)
When you make a API call, the response header includes an ETag with a value that is the hash of the data returned in the API call. You store this ETag value for use in the next request.
The next time you make the same API call, you include the If-None-Match request header with the ETag value stored from the first step.
If the data has not changed, the response status code will be 304 – Not Modified and no data is returned.
If the data has changed since the last query, the data is returned as usual with a new ETag. The game starts again: you store the new ETag value and use it for subsequent requests.
The main reason for using conditional GET requests is to reduce data traffic.
Isn't this only used for limiting resources?
You can ask an API for multiple resources in one request.
(Ok, thats also limiting resources by saving the other requests.)
You can prevent a method (e.g. PUT) from modifying an existing resource, when the client believes that the resource does not exist (replace protection).
I can obtain the resources with or without it?
When you ignore the "MUST use conditional GET" then (a) the traffic will increase and (b) you lose the "resource has changed" indication coming from server-side. You would have to implement the comparison handling on client side: is the resource of the second request newer than the one from the first request.
Comment for this answer: This was great thanks for taking the time to explain this in a cohesive manner. I have one more small question and its piggy backing on something you said in "(b)"  in your last paragraph. And that is if you don't use a comparison handle i.e "resource has changed" you'll get a 200 OK response so that would leave me to believe because you're always getting the newest/freshest data i.e. FIFO and you wouldn't need to worry about comparing right? Or is it FILO?
Comment for this answer: I'm glad i could help a bit. Yes, you would request the latest version of the resource (even if you already have it). When the requested data is only displayed (FIFO style), then you won't run into problems when fetching with a normal GET instead of a conditional GET. It starts to get tricky, when you store the data into a database.

Here is another answer: I found my question wasn't asking the "right question" due to me merging my understand of other headers (thanks to @dcerecedo's comment to get my pointed in the right direction) that were affecting my understand of why MUST was being used.
The MUST was more relivent to other headers, in my case private, max-age=3600 and must-revalidate
Cache-Control: private restricts proxy servers from caching it, this helps you keep your data off a server you dont trust and prevents a proxy from caching user specific data that’s not relevant to everyone (like a user profile).
Cache-Control "max-age=3600, must-revalidate" tell both client caches and proxy caches that once the content is stale (older than 3600 seconds) they must revalidate at the origin server before they can serve the content. This should be the default behavior of caching systems, but the must-revalidate directive makes this requirement unambiguous.
Where after the max-age expires the client should revalidate. It might revalidate using the If-Match or If-None-Match headers with an ETag, or it might use the If-Modified-Since or If-Unmodified-Since headers with a date. So, after expiration the browser will check at the server if the file is updated. If not, the server will respond with a 304 Not Modified header and nothing is downloaded.

{'source': 'StackExchangeDataset', 'subset': 'stackoverflow.com', 'metadata': {'AnswerCount': 2, 'CommentCount': 2, 'ContentLicense': 'CC BY-SA 3.0', 'CreationDate': '2015:00:10/29/15', 'FavoriteCount': 2.0, 'PostTypeId': 1, 'Tags': '<rest><http><http-headers><cache-control><etag>', 'Title': 'Why would ETags set to a MUST requirement if you already have the resource?', 'ViewCount': 4065, 'id': 33423987, 'user_AboutMe': '<p>JavaScript Enthusiast focused on JavaScript Paradigms, Design Patterns, and Best Practices —  ReactJs, ESNext, Codemods, Transformers</p>\n', 'user_AccountId': 5897986.0, 'user_DisplayName': 'garrettmac', 'user_Reputation': 8192.0, 'user_Views': 289.0, 'user_id': 4642530.0}}