paperclip VS okapi

The first bit I tried was following pieces of the official actix-web tutorial in order to get a tiny little web server started locally. This went fine, but was actually a big mistake as that tutorial teaches you to use macros to define endpoints which, at the time of writing, Paperclip does not support.

The biggest issue with Paperclip is that it only currently supports OpenAPI v2. There is work in progress to add v3 support, but it's just that: in progress. This means that if I really want to supplant FastAPI with this actix-web w/ Paperclip combo, I'm going to have to write my own v3 implementation. There is a GitHub Issue which talks about the intended strategy for achieving this being somehow based on converting a v2 spec to v3. I'm not sure how possible this will be considering there are some important features missing from v2. It makes more sense to me for this to be a different feature via cargo flag (or at least a different module).

It's inspired by others in the space that you might check out: paperclip, okapi, and others.

okapi: supports rocket

okapi looks decent as well. Has codegen for Rocket: https://github.com/GREsau/okapi

I have used it the other way around. I created the Rust code and using that to generate the documentation. https://github.com/GREsau/okapi this worked very good. Here is the generated documentation: https://docs.dfstoryteller.com/rapidoc/ This uses the Rust Doc comments to populate the documentation.

Oh Rocket, you playful muse. I've watched you ascend from my early Rust days; yet each time I reach for you my heart sinks more. This research project of mine led me to okapi, an extension for OpenAPI documentation. And yet, I have to pass once again. While most of the Rust ecosystem blazes toward async, you inch toward it too slowly. Perhaps next time I search for a web framework our paths will align, but until then, I must follow a different orbit.