> you could pass it through an anchor that wouldn't make it back server side. I.e. restbase or the API would give this to the client:  /someimage#o=vec&oh=1024&ow=768 This way we would avoid having to strip that context in Varnish and generally polluting the logs and information server-side with client-passed context that might actually not match the real values stored.

I really like this idea. It retains the advantage of encoding the information in a standard way in the URL, but avoids sending back unnecessary bits to the server. It follows the precedent of using url-encoded anchors in [media fragments](https://www.w3.org/TR/media-frags/). They are still straightforward to parse.

> Formats of the same "type" have fundamental differences already and you can't predict what new formats we'll support in the future. Knowing something is "vector" is of little use to the client if depending on the actual source file type one might not be able to convert it into some thumbnail types, etc.

I believe the conversion from vector (or video) to bitmap will always be possible, and is the conversion that is interesting to clients. Do you have concrete use cases in mind that would *require* more exotic format conversions, and aren't covered by the combination of Accept header, format selector, size & quality?

> Our current set of supported file types is too limited to know with certainty that this level of abstraction makes sense in a future-proof manner, and things will get very sketchy if we want to break an existing group like "vector" into subgroups in the future. If we start off with mime types, that never changes.

We could add an exact mime type in addition to the vector / bitmap / video distinction later (ex: `om=image/svg+xml`), if we find an actual use case that requires it. For current use cases, I think that dealing with the low-level file types mostly adds unnecessary complexity to clients, and reduces flexibility for phasing in new formats on the server. Even if we add finer-grained information & selection control at some point, most clients will probably continue to prefer using the simplest possible solution that satisfies their requirements.