Idiomatic OCaml REST backend?

What is a good tutorial for an idiomatic OCaml REST backend? I’m just looking for something with good defaults instead of reinventing everything myself.

So far the closest I have found is Joe Thomas | Writing a REST API with Dream

Suggestions ?

I don’t think there exists an “idiomatic” way of implementing REST web servers in OCaml – the closest thing is probably Dream, which you found. There’s also @rgrinberg’s opium, which is more analogous to Ruby’s Sinatra.

If you’re looking for examples to work off of in particular, dream has a whole host of them, as does opium.

Dream does seem to have all the basic elements you would expect put together in a clear and straightforward way. The documentation and examples can get you started quickly.

1 Like

Depends on what you mean by ‘REST’. If you mean the common understanding of ‘HTTP API with request and response bodies encoded as JSON objects’, then Dream can do the job pretty well. If you mean something closer to Roy Fielding’s hypermedia stuff, technically HTML is the closest you can get to that, and a backend that renders HTML responses is a REST API :slight_smile:

Upon reflection, I think “Ruby on Rails Replacement” might have been clearer.

I think the closest we have to that is Sihl.

I haven’t used it myself, but if one is interested in doing “real” REST, then GitHub - inhabitedtype/ocaml-webmachine: A REST toolkit for OCaml might be worth looking at. I don’t know how complete/faithful to the classic Erlang-based webmachine implementation; but if it’s close, then it should be a great tool to consider.

I added a simple webmachine implementation to the techempower benchmark and it’s basically Python level performance so I don’t think that’s a good choice :sweat_smile:

I don’t know anything about those benchmarks, but that webmachine result outranks django’s (for example), which is of course widely used. I like performance like anyone else, but it’s not the only factor. Webmachine-esque approaches are uniquely appealing if one is interested in being precise in one’s implementation of the fullest breadth of HTTP compliance, so it’s never going to be as fast as an approach that just mounts a pile of routes and handlers of interest (my usual approach, for example).