Servant supports defining the same route multiple times with different
content-types and result-types, but servant-docs was only documenting
the first of copy of such duplicated routes. It now combines the
documentation from all the copies.
Unfortunately, it is not yet possible for the documentation to specify
multiple status codes.
- WIP: pending http-api-data release
- TODO: remove MIN_VERSION_http_types
- There have been 3 major releases of http-types:
- 0.10 change name of variable
- 0.11 lowercase escaped URIs
- 0.12 uppercase escaped URIs
- It's easier for us to support only latest, migration from 0.9/0.10 to 0.12
is trivial for the downstream. 0.11 may cause semantic (non-type-error) breakage somewhere.
Also allow lens-4.16, remove MIN_VERSION_http_types conditionals, and
update `stack.yaml`
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).
The changelog for `servant` contains changes across core packages,
as we release them as a suite.
Also added links to the GitHub master as we might update entries
for old versions, as changelogs are written by humans.
- Add build-tool-depends, so new-build can use hspec-discover
- Add mtl bounds in tutorial (and dependency on mtl-compact)
- Add extra-source-files to tutorial, so it's buildable from sdist
For some reason, 2nd-level headings are used for introductions and for
each API endpoint, but then it immediately jumps to 4th-level
headings.
Instead, promote everything that's 4th-level to 3rd-level.
This relies on the behaviour of pandoc, and as such may not apply to
other Markdown renderers.
Before this change, you would have something like:
> - Example: `application/json`
>
> ```javascript
> "HELLO, HASKELLER"
> ```
When converting this to HTML, PDF, etc. the code block is _not_
contained within the bullet point.
With this change, the generated markdown looks like:
> - Example: `application/json`
>
> ```javascript
> "HELLO, HASKELLER"
> ```
With pandoc at least, this effectively indents the entire code block
to be under the bullet point, which is the intended effect.
Note that the code itself is _not_ indented (which might break other
Markdown renderers) as to do so would require splitting on newlines,
which may have unintended consequences when dealing with generated
values (may contain `\r\n`, etc.).
Currently, it appears after the notes, authentication and capture
information... such that if any of those exist, then the list of
header sensitivity will appear to be an item of one of the previous
ones (as they provide Markdown headers).
