4This is an introductory tutorial to the current version of *servant*, which is **0.4**. Any comment or issue can be directed to [this website's issue tracker](http://github.com/haskell-servant/haskell-servant.github.io/issues).
9- the servant packages: [haskell-servant/servant](https://github.com/haskell-servant/servant)
10- the website (including this tutorial): [haskell-servant/haskell-servant.github.io](https://github.com/haskell-servant/haskell-servant.github.io/)
11- Feel free to use the issue tracker (or to send PRs!) on the website's repository to give feedback and suggestions about this tutorial
16*servant* has the following guiding principles:
20 This is a pretty wide-ranging principle. You should be able to get nice
21 documentation for your web servers, and client libraries, without repeating
22 yourself. You should not have to manually serialize and deserialize your
23 resources, but only declare how to do those things *once per type*. If a
24 bunch of your handlers take the same query parameters, you shouldn't have to
25 repeat that logic for each handler, but instead just "apply" it to all of
26 them at once. Your handlers shouldn't be where composition goes to die. And
31 If we haven't thought of your use case, it should still be easily
32 achievable. If you want to use templating library X, go ahead. Forms? Do
33 them however you want, but without difficulty. We're not opinionated.
35- separation of concerns
37 Your handlers and your HTTP logic should be separate. True to the philosphy
38 at the core of HTTP and REST, with *servant* your handlers return normal
39 Haskell datatypes - that's the resource. And then from a description of your
40 API, *servant* handles the *presentation* (i.e., the Content-Types). But
41 that's just one example.
45 Want to be sure your API meets a specification? Your compiler can check
46 that for you. Links you can be sure exist? You got it.
48To stick true to these principles, we do things a little differently than you
49might expect. The core idea is *reifying the description of your API*. Once
50reified, everything follows. We think we might be the first web framework to
51reify API descriptions in an extensible way. We're pretty sure we're the first
52to reify it as *types*.
54To be able to write a webservice you only need to read the first two sections,
55but the goal of this document being to get you started with servant, we also
56cover the couple of ways you can extend servant for a great good.
keysesc to close
- j k
- move down, up
- enter
- open
- esc
- back, or up a level
- 1 2 3 4
- readme, files, commits, refs
- /
- filter
- y
- copy the clone command
- c
- compare the chosen commit with another (or shift-click both)
- ?
- show or hide this list