git.iko.soy/typeable/wai
on wai-extra/3.0.20.2 help sign in
typeable/wai/hcar-wai.tex
52 lines 1.8 kB history raw
1% WAI-KW.tex
2\begin{hcarentry}{WAI}
3\label{wai}
4\report{Kazu Yamamoto}%11/17
5\participants{Michael Snoyman, Greg Weber}
6\status{stable}
7\makeheader
9WAI (Web Application Interface) is an application interface between web
10applications and handlers in Haskell. The \texttt{Application} data type is
11defined as follows:
13\begin{verbatim}
14type Application
15 = Request
16 -> (Response -> IO ResponseReceived)
17 -> IO ResponseReceived
18\end{verbatim}
20That is, a WAI application takes two arguments: a \texttt{Request} and a
21function to send a \texttt{Response}. So, the typical behavior of WAI
22application is processing a request, generating a response and passing the
23response to the function.
25Historically speaking, this interface made possible to develop handlers other
26than HTTP. The WAI applications can run through FastCGI
27(wai-handler-fastcgi), run as stand-alone (wai-handler-webkit), etc. But the
28most popular handler is based on HTTP, of course. The major HTTP handler for
29WAI is Warp which now provides both HTTP/1.1 and HTTP/2. TLS (warp-tls) is
30also available. New transports such as WebSocket (wai-websocket) and Event
31Source (wai-extra) can be implemented, too.
33It is possible to develop WAI applications directly. For instance, Hoogle and
34Mighttpd2 take this way. However, you may want to use web application
35frameworks such as Apiary, MFlow, rest, Servant, Scotty, Spock, Yesod, etc.
37WAI also provides \texttt{Middleware}:
39\begin{verbatim}
40type Middleware = Application -> Application
41\end{verbatim}
43WAI middleware can inspect and transform a request, for example by
44automatically gzipping a response or logging a request (wai-extra).
46Since the last HCAR, no major changes were made.
48\FurtherReading
49\begin{compactitem}
50\item\url{https://groups.google.com/d/forum/haskell-wai}
51\end{compactitem}
52\end{hcarentry}