Move `HasServer (NamedRoutes routes)` instance
The instance has been moved to `Servant.Server.Internal`, as the
instances for other combinators. It is necessary so that the instance
can be re-exported from `Servant.Server` without circular imports.
Otherwise, users have to import `Servant.Server.Generic` manually ;
forgetting to do so will produce confusing error messages about the
missing instance.
Move `HasClient (NamedRoutes routes)` instance
Moved so that the instance is made available when importing
`Servant.Client`, avoiding possibly confusing errors when
`Servant.Client.Generic` isn't imported.
Allows users to directly embed APIs defined as records of routes into
vanilla Servant API types.
E.g.:
```haskell
data MyRoutes mode = MyRoutes
{ version :: mode :- Get '[JSON] Int
, …
}
type API = "prefix" :> NamedRoutes MyRoutes :<|> …
```
APIs can thus be recursively defined directly with Generic record types.
We do not need the `ToJSON` instance for `WithStatus`
it would cause an overlap between:
```
ToJSON a => MimeRender JSON a
```
and
```
forall cty a. MimeRendercty a => MimeRender cty (WithStatus a)
```
and Servant just needs the `MimeRender` typeclass for it to work
* Add some more docs to the UVerb module
* cookbook/uverb: Change GHC versions
CI was complaining some version did not exist. Trying to bump
Also added 8.10.1
* doc/cookbook/uverb: Remove 8.4.4 from tested versions
CI was running into a cabal bug for some reason
Currently there is no way for Servant users to customize formatting of
error messages that arise when combinators can't parse URL or request
body, apart from reimplementing those combinators for themselves or
using middlewares.
This commit adds a possibility to specify custom error formatters
through Context.
Fixes#685
- Rename GenResponse to ResponseF (analogous to RequestF)
- add NFData Headers
- Make Request and Response bodies be SourceIO,
i.e. move conversions into specific implementations
- Introduce SourceT, which is simple variant of "correct `ListT`".
There are another variants possible (like in `streaming`),
but I'm not sure there's much real difference.
- Introduce `Codensity`. There's a flag if people don't want to depend
on `kan-extensions`.
- `StreamGenerator` and `ResultStream` are both `SourceT`.
`Stream` combinator in `servant-client` uses `Codensity` for CPS.
- Add servant-machines, servant-conduit, servant-pipes
- Add streaming cookbook: just code, no explanations.
- Add a script to run streaming 'benchmarks'
- Add Streaming endpoint to the comprehensive API.
- Rename BuildFromStream to FromResultStram
- I'm tempted to rename everything in the Servant.API.Stream
(add some prefixes, `header` is too good name to steal)
The TODO in `servant-docs` is left intentionally.
Changes Header, ReqBody and QueryParam to take a modifier list.
Resolves https://github.com/haskell-servant/servant/issues/856
ResponseHeader story turns to be somewhat ugly, but it can be made
elegant when https://github.com/haskell-servant/servant/issues/841 is
implemnted, then we can omit HList aka Header Heterogenous List
implementation.
- servant-server changes:
Writing server side intepretations is quite simple using
`unfoldRequestArgument`, which makes Header and QueryParam look quite
the same.
`ReqBody` cannot be easily made optional with current design (what that
would mean: No Content-Type Header?), so that dimensions isn't used
there.
- Add HasLink for all the rest ComprehensiveAPI combinators
- Add 'tricky' Header', QueryParam' endpoints to ComprehensiveAPI
- servant-docs: Quick'n'dirty implementation. Don't use modifiers information (yet).
