All sounds good and I’m sure I’ll learn from your APIs as they are as well. I also have a mix including multi-part, binary, JSON etc. Another area of difference may be how we return struct results - for example when doing put/get I’m using Rust structs with utoipa Schemas. I see you added swaggerUI so are you also using utoipa for docs/SwaggerUI? If so us both using the schema of common Rust structs would be a good way to go.
I don’t have strong feelings about the paths except for… /v1 etc which I explain below, but first another possibility that occurs to me is for us to standardise on the base APIs (/ant /api or whatever) and to allow a header which enables extra features. That might simplify some areas of the handler code, but tbh it will just make the docs harder to explain, having optional features in many APIs all enabled by a custom header. But I mention it anyway.
Back to why I avoided /v1 etc for versioning: that was because I wanted an optional ‘version’ in the path of APIs which accept a History (which is quite a few) so I went from /ant/v0 to /ant-0 and can use /archive-version/[v<VERSION-NUMBER>/]<ADDRESS-OR-NAME> where ADDRESS-OR-NAME resolves to a History (similar to Register).
I use that in several my APIs (e.g. for links to another website with /dweb-open/[v<VERSION-NUMBER>/]<ADDRESS-OR-NAME><REMOTE-PATH>). The version is optional because you can leave it out, in which case you get the most recent version in the History. I’d planned to use the same convention for Registers. So I wanted to avoid having another /vN in the path. Normally I’m a slave to such conventions 
I suggest we pull this into its own topic so I’ll copy my first post onto the topic below, and if you can copy your reply there, I’ll reply to that with this. If that make sense 