You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At our workplace we use OpenAPI3 and are very grateful for the work that was put in it.
Recently we have taken to move away from using Aeson's Value, as it does not preserve key ordering. While JSON applications should not rely on it, it's actually quite useful for examples as similar fields are declared next to another, and we usually want some "Id" field to be the first one displayed. For example, last_name and first_name should be together.
Now, I'm not suggesting to break the compatibility by changing the type of _schemaExample :: Maybe Value to something incompatible, but rather open more possibilities by having something like an existentially-quantified type:
Hi @maksbotan!
At our workplace we use OpenAPI3 and are very grateful for the work that was put in it.
Recently we have taken to move away from using Aeson's
Value
, as it does not preserve key ordering. While JSON applications should not rely on it, it's actually quite useful for examples as similar fields are declared next to another, and we usually want some "Id" field to be the first one displayed. For example,last_name
andfirst_name
should be together.Now, I'm not suggesting to break the compatibility by changing the type of
_schemaExample :: Maybe Value
to something incompatible, but rather open more possibilities by having something like an existentially-quantified type:and use directly
encode
in the library to render the ByteString.How does this sound? I can submit a PR if you agree on the design. :)
The text was updated successfully, but these errors were encountered: