ApiToApplication with no initial server state

[Alistair Burrowes]

Hi,

I am new to Haskell and I am trying to write a crud style api using WAI which will not be loading in any initial server state.

The rest-example loads in a bunch of dummy data and I am not sure how use apiToApplication without this. I basically want a hello world esque example.

What would

apiToApplication (runBlogApi serverData) api

become without a step of filling up the serverData.

Apologies if there is a better forum for this question. I couldn't find anything.

Cheers,
Alistair

[Adam Bergmark]

Hi Alistair,

This is not straight-foward unless you figure out the types involved. We have apiToApplication :: Run m IO -> Api m -> Application.

What's Run? See the documentation and click Run to go to its definition. It's just a type alias, if we inline it we get apiToApplication :: (forall m. m a -> IO a) -> Api m -> Application. So this is a function that takes some type m and turns it into (i.e. runs it in) IO. If you don't want any extra state your api can just run in IO so you need a function IO a -> IO a. That's just id and we end up with

apiToApplication' :: Api IO -> Application
apiToApplication' = apiToApplication id

Admittedly I find that the type alias just obfuscates this code, perhaps we should remove it. What do you think @hesselink?

rest-happstack provides another function to do just this so we should at least be consistent across the backends I think.

Hope this helps!

PS. Since you asked, we have a mailing list for all our FLOSS software, but I don't really care where questions are asked.

[Alistair Burrowes]

Thanks I got that working. Yeah I was struggling because the happstack example in the tutorial has a clear example on this but couldn't find anything equivalent with wai (and couldn't figure it out with my noob Haskell skills).

[Erik Hesselink]

I'm not sure if removing the type synonym would make things clearer or not. It's always the tradeoff with type synonyms: they make signatures shorter and more easy to manage, but you might have to look up the synonym definition.

There's a typo in your expansion btw, the forall is on the a, not the m: apiToApplication :: (forall a. m a -> IO a) -> Api m -> Application.

As for the functions we provide, I've not been very happy with what we have. The apiToHandler'/apiToApplication functions are fine since they are generic, but the happstack and snap apiToHandler functions aren't that great since usually you don't want the web framework monad to be visible in the API type. An IO version for all of them might make more sense, though.