The way this does routing leads to quite hard to read code, compare <a href="https://www.okapi.wiki/docs/todo-app" rel="nofollow">https://www.okapi.wiki/docs/todo-app</a>:<p><pre><code> todoAPI conn = getTodo conn <|> getAllTodos conn
</code></pre>
with<p><pre><code> getTodo conn = do
methodGET
pathParam @Text `is` "todos"
todoID <- pathParam @Int
...
</code></pre>
so you need to keep in mind both the order of the alternatives in todoAPI as well as the bodies of the individual handlers. That gets unwieldy very quickly.<p>It also seems likely to lead to the same problems with error handling that you tend to get with combinator parsers, where you usually only get details about the last failing branch, while the interesting failure might have been an earlier one.<p>Quiz question (I don't know the answer): What happens to a request for /todos/foo?
Looks really nice but I haven’t tried it yet. I wrote a small book on my take on Haskell programming using a small subset of the language (read for free on my web site <a href="https://markwatson.com" rel="nofollow">https://markwatson.com</a>). When I update my book I might add an Okapi example. I have played around with Spock for simple web apps and that is nice enough, but I am really impressed by the care in putting together the Okapi documentation web site. Great material, nicely presented.
The author of this framework is also doing very interesting work on building Haskell server pages [1], taking inspiration from redbean's Lua server pages[2].<p>[1] <a href="https://monadic.systems/post7" rel="nofollow">https://monadic.systems/post7</a>
[2] <a href="https://redbean.dev/#lua" rel="nofollow">https://redbean.dev/#lua</a>
In case anyone else who's played with search engines thinks, "Wait, Okapi sounds familiar," here you go: <a href="https://en.wikipedia.org/wiki/Okapi_BM25" rel="nofollow">https://en.wikipedia.org/wiki/Okapi_BM25</a><p>The "Get Started" and "View on GitHub" links both have `href="/"`, so they don't work.