Hi,
I'm having troubles writing my code which interacts with the Nav OData web services, in particular because of differences between environments.
In short, there are two environments I'm communicating with: Test and Prod, for the same customer.
When I request data from the test environment, I receive a list of items, and each item has an ETag:
"@odata.etag": "W/\"JzU2O2h4WUFBQUNMQVFBQUFBSjcvMVlBU0FCR0FEQUFNQUF3QURFQU13QTJBQUFBQUljUUp3QUFBQUE9MTA7NzI2MzcwNDEzMDA7Jw==\"",
When I request data from the exact same resource in the production environment, I get the ETag a bit differently, i.e. there are two properties this time:
"odata.etag": "W/\"'56%3BhxYAAACLAQAAAAJ7%2F1YASABGADAAMAAwADIANQA5AAAAAIcQJwAAAAA%3D10%3B11808877060%3B'\"",
"ETag": "56;hxYAAACLAQAAAAJ7/1YASABGADAAMAAwADIANQA5AAAAAIcQJwAAAAA=10;11808877060;"
Note: the entities in question are of the same type but contain different data, hence the difference in the ETag values themselves.
I've learned that the difference between the ETags which start with "W/\" and those which don't is that the "W/\" prefix denotes a "Weak" ETag, while the other is a strong ETag.
However, what I haven't figured out is the following:
- Why the difference in property names? Why both odata.etag and @odata.etag? (I have a workaround for this, this just strikes me as strange).
- Why the difference in the format of the weak ETags? If you inspect the value of the odata.etag and the @odata.etag, you will notice that one has a set of single quotes around the actual etag, but the other doesn't.
- Why the difference in the format of the weak vs. strong etags? There seems to be some kind of encoding going on, which encodes characters such as ;, /, = and possible others. What type of encoding is applied there?
Is there a resource somewhere which discusses this?
The real reason for my troubles is that I'm writing code which updates said resources. I've managed to get this to work on the test environment, but not in the production environment, and I suspect that the differences listed above may be a part of the reason why, but I cannot be sure until I've solved this.
Regards,
DanÃel