Open whatamithinking opened 3 months ago
Bytes have default (de)serializer registered is on purpose to make it convenient for user as it base64 is AFAIK the "standard" way of doing.
If your API use an other format, you can register a different (de)serializer, and override the default one. That's the "recommended approach": leveraging apischema adaptability.
Or you can also use different types as you're doing in your code if you're mixing encoding. But the purpose of apischema is to not embed these custom types in its own code; I don't want a pydantic-like mess with dozens of predefined conversions provided when 3 lines of code are enough, thanks to conversion feature. apischema should only supports standard types, with an appropriate default (de)serializer.
The fact you opened the issue may highlight the lack of a dedicated example in the documentation, or maybe a FAQ. I will keep this issue opened as a reminder.
I think I understand where you are coming from, but it seems like a library with so much focus on openapi should support the different encodings that standard calls out, which are finite and supported by the base64
package in the python standard library. Adding support for these encodings internally, one way or another, would allow things to seemingly "just work" from the perspective of newcomers and could make apischema more of the goto for anyone solely focused on working with openapi, as I am.
Open API / JSON Schema have different encodings (base64, base32, base32hex, etc.) apischema does not seem to support these out of the box and instead base64 encodes all bytes. What is the recommended approach to supporting these?
I have a workaround (see below), but it might help others if other encodings were built in, maybe in a way that avoids creating custom types as I have below.