Hello @Daniele Rossi,
According to the MDN Web Docs on ETags - if the resource at a given URL changes, a new ETag value must be generated. As I understand it, POST, PUT or DELETE requests change what’s at the other end (either by creating, updating or destroying), and thus need an ETAg, but a GET would not change anything. This would explain why only the GET requests do not require the ETag.
However, according to the RESTCONF Protocol Draft from the IETF, GET requests often do contain ETags. This has has to do with some complicated interactions between the Last-Modified, ETag, If-Match, If-Modified-Since and If-Unmodified-Since headers.
RESTCONF Request Headers
| Name |
Description |
| Accept |
Response Content-Types that are acceptable |
| Content-Type |
The media type of the request body |
| Host |
The host address of the server |
| If-Match |
Only perform the action if the entity matches ETag |
| If-Modified-Since |
Only perform the action if modified since time |
| If-Unmodified-Since |
Only perform the action if un-modified since time |
RESTCONF Response Headers
| Name |
Description |
| Allow |
Valid actions when 405 error returned |
| Cache-Control |
The cache control parameters for the response |
| Content-Type |
The media type of the response body |
| Date |
The date and time the message was sent |
| ETag |
An identifier for a specific version of a resource |
| Last-Modified |
The last modified date and time of a resource |
| Location |
The resource identifier for a newly created resource |
It states:
Since the datastore contents change at unpredictable times, responses from a RESTCONF server generally SHOULD NOT be cached.
The server SHOULD include a "Cache‑Control" header in every response that specifies whether the response should be cached. A "Pragma" header specifying "no‑cache" MAY also be sent in case the "Cache‑Control" header is not supported.
Instead of using HTTP caching, the client SHOULD track the "ETag" and/or "Last‑Modified" headers returned by the server for the datastore resource (or data resource if the server supports it). A retrieval request for a resource can include the "If‑None‑Match" and/or "If‑Modified‑Since" headers, which will cause the server to return a "304 Not Modified" Status-Line if the resource has not changed. The client MAY use the HEAD method to retrieve just the message headers, which SHOULD include the "ETag" and "Last‑Modified" headers, if this meta-data is maintained for the target resource.
That IETF doc isn't too long and it reads nicely for a doc. If you want to understand the intricacies, you can have a read.
Hope this helps!
