Dragomir Ivanov

Thanks for the response. I think having that feature can be very useful.

@h2non Thanks for the fast response. I am thinking if I go the route you have suggested with the simpler counter, didn't I loose the server balancing functionality. Perfectly the...

Thanks for the deep analysis. I don't think `field-selection` is even applicable, at least for the issue in my mind. Here is my workflow in mind for PUT/PATCH. 1. Client...

I see now, didn't thought of passing projection to PUT/POST/PATCH. In any case server should return what it has. Whether or not, or how client consumes this data is not...

One issue I see, is that PUT, can return 200 or 201 depending on whether item exists or not. However returning just 204 from here, will obscure that knowledge. Don't...

Thanks @smyrman . Please find above a preview of one possible solution. No tests and README updates for now.

Actually, I don't have any special sympathy to 204. I will be equally happy with 200/201 with empty body. My models are heavily updated and I use `Prefer return=minimal` to...

Thanks @smyrman . Yes, `gzip` is mandatory these days. I am doing it on the reverse-proxy server, though, along with HTTPS termination. Using Caddy server.

@smyrman I think backward-compatibility doesn't need to be a problem at this stage. Moreover we don't know how many users rest-layer has, and maybe such breaking change is a good...

@rs `services` and `visits` are bound to `clients` by `schema.Reference` and not `schema.Connection` so `*,services,visits` results in an arrays of `services:[]` and `visits:[]` attached to the returned clients item. Composite...