Sindre Røkenes Myren

> Can you rethink your decision on using XOR of all ETags instead. I suppose that means that rs/rest-layer-mongo#20 would need to change to a compatible format? > sometimes sub-resources...

I suppose it _is_ true that they can come from the DB at different times, but does that matter?

> We will need ether store&compute this hash after all sub-resources have been obtained from storage, or use algorithm where ordering doesn't matter (XOR). Ok, I follow you now. I...

> From me just skimming the code, it looks like the order is pretty much guaranteed (unless they come in a random order from the Storer layer). I was thinking...

> We can handle different sizes using padding when necessary. That only works if the non-conforment ID has a length _shorter_ then the typical MD5 sub. Maybe better to just...

`"$eq"` is not recognized as an operator by rest-layer. All operators currently handed can be found here: https://github.com/rs/rest-layer/blob/369f453dbbffee4c7c275e8038c8bbed5fbf8b5a/schema/query/predicate.go#L12

rest-layer only aims to support/allow a sub-set of the MongoDB query syntax, but in this case I agree. We can just add it. Unfortunately the amount of time I have...

Personally I feel it's a reasonable limitation for `rest-layer` to require an ID field that is actually named `"id". In my mind, this enforces a more consistent API, and you...

First of all, if you are _able_ to modify the database to have a separate ID column, either a unique ID (e.g. xid) or a unique random ID (e.g. UUID...

@Dragomir-Ivanov , @rs - to continue the discussion here. We have discussed two options previously: 1. Allow `_etag` to be specified in fields. 2. Allow a separate flag, e.g. `etag=1`...