json-spec: Type-level JSON specification

[ json, library, mit ] [ Propose Tags ]

Downloads

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees

Candidates

  • No Candidates
Versions [RSS] 0.1.0.0, 0.2.0.0, 0.2.1.0, 0.2.1.1, 0.2.1.2, 0.2.1.3, 0.2.2.0, 0.2.3.0, 0.3.0.0, 0.3.0.1, 0.4.0.0, 0.4.1.0, 0.5.0.0 (info)
Dependencies aeson (>=2.0.3.0 && <2.3), base (>=4.16.0.0 && <4.20), containers (>=0.6.4.1 && <0.7), scientific (>=0.3.7.0 && <0.4), text (>=1.2.5.0 && <2.2), time (>=1.9.3 && <1.13), vector (>=0.12.3.1 && <0.14) [details]
License MIT
Author Rick Owens
Maintainer rick@owensmurray.com
Category JSON
Home page https://github.com/owensmurray/json-spec
Uploaded by rickowens at 2024-05-24T22:47:04Z
Distributions Stackage:0.3.0.1
Reverse Dependencies 3 direct, 0 indirect [details]
Downloads 341 total (66 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs uploaded by user
Build status unknown [no reports yet]

Readme for json-spec-0.5.0.0

[back to package description]

json-spec

Motivation

The primary motivation is to allow you to avoid Aeson Generic instances while still getting the possibility of auto-generated (and therefore /correct/) documentation and code in your servant APIs.

Historically, the trade-off has been:

  1. Use Generic instances, and therefore your API is brittle. Changes to Deeply nested object might unexpectedly change (and break) your API. You must structure your Haskell types exactly as they are rendered into JSON, which may not always be "natural" and easy to work with. In exchange, you get the ability to auto-derive matching ToSchema instances along with various code generation tools that all understand Aeson Generic instances.

  2. Hand-write your ToJSON and FromJSON instances, which means you get to structure your Haskell types in the way that works best for Haskell, while structuring your JSON in the way that works best for your API. It also means you can more easily support "old" decoding versions and more easily maintain backwards compatibility, etc. In exchange, you have to to hand-write your ToSchema instances, and code generation is basically out.

The goal of this library is to provide a way to hand-write the encoding and decoding of your JSON using type-level 'Specification's, while still allowing the use of tools that can interpret the specification and auto-generate ToSchema instances and code.

The tooling ecosystem that knows how to interpret 'Specification's is still pretty new, but it at least includes OpenApi compatibility (i.e. ToSchema instances) and Elm code generation.

Example

data User = User
  { name :: Text
  , lastLogin :: UTCTime
  }
  deriving stock (Show, Eq)
  deriving (ToJSON, FromJSON) via (SpecJSON User)
instance HasJsonEncodingSpec User where
  type EncodingSpec User =
    JsonObject '[
      Required "name" JsonString,
      Required "last-login" JsonDateTime
    ]
  toJSONStructure user =
    (Field @"name" (name user),
    (Field @"last-login" (lastLogin user),
    ()))
instance HasJsonDecodingSpec User where
  type DecodingSpec User = EncodingSpec User
  fromJSONStructure
      (Field @"name" name,
      (Field @"last-login" lastLogin,
      ()))
    =
      pure User { name , lastLogin }

For more examples, take a look at the test suite.