allow unknown string format properties

[acgray]

Addresses #64

[codecov]

Codecov Report

Merging #65 into master will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #65   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           10        10           
  Lines          671       669    -2     
=========================================
- Hits           671       669    -2     

Impacted Files	Coverage Δ
openapi_python_client/openapi_parser/properties.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 05b3784...3cbc3a3. Read the comment docs.

[dbanty]

Thanks @acgray this looks good. The only concern I have is that support for the "byte" format has not been added yet, and I would expect that type to use the Python bytes type instead of str. Could you add back in the parse error specifically for that format? You could also add support for the format if you're feeling up to it.

[acgray]

Sure, although given the content-type is currently assumed to be application/json, the case of a field containing raw bytes inside a JSON object seems to me to be relatively unlikely. Did you have a use-case in mind that I'm missing?

[dbanty]

Sure, we work with IoT which pushes some packed binary data up to save space. Most of these don't use an OpenAPI endpoint right now but we're moving everything in that direction. Some visible metadata can go in JSON keys while the main fat payload can be a big binary blob.

We do also support "application/x-www-form-urlencoded" and "multipart/form-data" in requests and "text/html" in responses. Though now that you mention it, I wonder if httpx is always picking the right content-type based on payload >.>. We don't explicitly set it today.

[dbanty]

After some more right on this, you're right @acgray. Embedding binary data within JSON is rare enough that we probably don't need to add support. With the generic string feature, that data should come through as a base64 encoded string, at which point the developers working with binary data presumably know what they want to do with it (which might not be the bytes type anyway).

I'm going to merge this one in and if someone complains about manually decoding data we can revisit decoding it in here.

[acgray]

Great to hear! Afraid work circumstances mean I'm very part-time on engineering right now, so apologies for the slow responses

…

On Sat, Jun 13, 2020 at 2:41 PM Dylan Anthony ***@***.***> wrote: Merged #65 <#65> into master. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com./notifications/unsubscribe-auth/AAGXHVU3XDDBJSYAL55YEZDRWN6ZRANCNFSM4NYKJ6RQ> .

[dbanty]

@acgray not a problem at all. Thanks for all your contributions!