4 ms·
And then you'd be limited to only one change at the time and lose the benefit of making lot of changes with one request.
by kukkamario 2y ago
And then you'd be limited to only one change at the time and lose the benefit of making lot of changes with one request.
- graypegg 2y agoI do get that, just saw the "test" op, to either pass or fail the whole change as a sort of transaction. That is really neat. But I just find that the 1 by 1 approach is easier to reason about if you're opening this up to the internet. I'd personally feel more comfortable with the security model of 1 URL + Session => 1 JSON key.
- mattmanser 2y agoI'm actually using it at the moment in my work and I'm often doing 3-4 updates per patch. You want them to all fail or not, One-by-one is a bit of a weird suggestion tbh. You shouldn't be reasoning that way about code. If you are going to get a 4xx response to one of the 4 property updates you want them all to fail at once. Just like anything else we use like SQL.
- vlowther 2y ago$WORK project heavily utilizes the test op to enable atomic updates to objects across multiple competing clients. It winds up working really well for that purpose.
- CrimsonRain 2y agoWho generates the test op? Client? Or the server?
- kchr 2y agoCan you elaborate on how this affects the security model?