Sinatra Like URL Route Processing (SLURP) is another route framework to define REST API à la Sinatra. SLURP is strongly typed and modular. It is not bound to a server definition so that anyone can use it in existing projects and new ones with custom servers (Cohttp, H2, Apache, Nginx or whatever).
SLURP is intented to be used with opam with:
opam install slurp
Server support comes with other package named slurp-xxx where xxx is the server name. Currently ony Cohttp is supported but other server will be added on demand (and with time). To install the Cohttp SLURP server stuff, simply use:
opam install slurp-cohttp
SLURP documentation can be found here.
At the time of writing, there are three related projects on opam that gives the same route based API definition: Opium, resto and OWebl. To be short, the table below summarize the differences between those projects and SLURP (as far I as understand them).
| Feature | Opium | Resto | OWebl | SLURP |
|---|---|---|---|---|
| Strongly typed | X | X | ||
| *|** support | X | ? | X(1) | |
| Query support | X | X | X(2) | |
| Body support | Manual | X | X | X |
| Stream support | Manual | X | ? | |
| Library | X | X | ||
| Export | Custom JSON | OpenAPI(3) |
- (1) I don't know if the semantic given to these operators is the common one, I'll check that someday...
- (2) The query part is operationnal but not with the intended usage. It will be fixed for a near version.
- (3) As planned with OpenAPI project which will give client code generation support.
As you can see, resto propose something close to SLURP but with some design issues I feel uncomfortable with. The API is a library but clearly designed to be used with Tezos which is great but I personnaly need something more basic, customizable ans standard for companies I work for.
The customization part is mandatory for the main users of this lib use customized REST API servers (given by SLURP) but with other custom services not necessarily related to the routing stuff.
This standard support is also mandatory for the API description can lead to code generation on client side with other languages (Python, Java or whatever) with existing code generators.
I really liked testing Opium for its raw simplicity suited well to some of my need but the tool isn't ready for industrial use because of its lack of modularity (in my point of view). I didn't tried much OWebl for its author claims himself to not use it in real project 😉.