eeva/servant
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Fixes issue #1206 by updating broken links in tutorial.

Browse source
This commit is contained in:
Noah Snelson 2019-10-07 11:23:30 -07:00
parent 6cf7c73824
commit ec80f251f3
3 changed files with 16 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
changelog.d/issue1206 Normal file
View file

@ -0,0 +1,13 @@
synopsis: Fix broken links in Tutorial documentation.
issues: #1206
description: {
In servant/doc/tutorial/Client.lhs, several links point to an .lhs file,
which show as broken in the live web documentation. Changing the suffix to
.html displays the correct documentation.
In servant/doc/tutorial/Authentication.lhs, a link to GHC documentation for
Type Families pointed to a 404'd page. A link to existing GHC documentation
was substituted.
}

2
doc/tutorial/Authentication.lhs
View file

@ -318,7 +318,7 @@ genAuthAPI = Proxy
Now we need to bring everything together for the server. We have the
`AuthHandler Request Account` value and an `AuthProtected` endpoint. To bind these
together, we need to provide a [Type Family](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/type-families.html)
together, we need to provide a [Type Family](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#type-families)
instance that tells the `HasServer` instance that our `Context` will supply a
`Account` (via `AuthHandler Request Account`) and that downstream combinators will
have access to this `Account` value (or an error will be thrown if authentication

4
doc/tutorial/Client.lhs
View file

@ -1,9 +1,9 @@
# Querying an API
While defining handlers that [serve an API](Server.lhs) has a lot to it, querying an API is simpler: we do not care about what happens inside the webserver, we just need to know how to talk to it and get a response back. That said, we usually have to write the querying functions by hand because the structure of the API isn't a first class citizen and can't be inspected to generate the client-side functions.
While defining handlers that [serve an API](Server.html) has a lot to it, querying an API is simpler: we do not care about what happens inside the webserver, we just need to know how to talk to it and get a response back. That said, we usually have to write the querying functions by hand because the structure of the API isn't a first class citizen and can't be inspected to generate the client-side functions.
**servant** however has a way to inspect APIs, because APIs are just Haskell types and (GHC) Haskell lets us do quite a few things with types. In the same way that we look at an API type to deduce the types the handlers should have, we can inspect the structure of the API to *derive* Haskell functions that take one argument for each occurrence of `Capture`, `ReqBody`, `QueryParam`
and friends (see [the tutorial introduction](ApiType.lhs) for an overview). By *derive*, we mean that there's no code generation involved - the functions are defined just by the structure of the API type.
and friends (see [the tutorial introduction](ApiType.html) for an overview). By *derive*, we mean that there's no code generation involved - the functions are defined just by the structure of the API type.
The source for this tutorial section is a literate Haskell file, so first we need to have some language extensions and imports: