Question about Rust http::Request and HTTP trigger roadmap

[captaincoordinates]

Question about Rust http::Request and HTTP trigger roadmap

[itowlson]

This is a great question. As a hosting framework, Spin should ideally not be too prescriptive about how to do things or access things: users must have access to the bottom level (wasi-http) to build their own choice of abstraction layer on top. But the SDK does provide higher level features too, such as routing or JSON body support. So it wouldn't be inconsistent to offer structured access to the query string, e.g. as a slice of key-value pairs. But we'd still want to keep the baseline representation, so that people who want to use (say) serde_query could use that instead.

The long-game hope/bet is that WASI Preview 2 (which is what defines Spin's base HTTP types) will become sufficiently widely accepted that the higher-level frameworks and libraries you describe will just transparently work with the WASI incoming-request type in future, so you won't be limited to what's in the Spin SDK (or what you build on top of it), in a similar way to how you can just use Rust file libraries, rather than being stuck with a Spin File SDK. But that's not where we are today.

So this ends up being kind of an evasive answer. We're certainly open to higher-level APIs in the Spin SDK, and delighted to take PRs that improve usability. Things that are strongly opinionated should typically be outside the SDK, layered above it in their own packages, similar to spin-contrib-http (https://github.com/ThorstenHans/spin-contrib-http, although a lot of that is pretty low level too!) or leptos-spin (https://github.com/fermyon/leptos-spin). But for things that are common and non-prescriptive, like extractors, builders, and parsers: yes, we would love to hear more or to accept PRs.

I hope that makes sense, and I know it's a long answer! Always happy to discuss further and to see how we can improve for our users!

[captaincoordinates]

Thanks for your input, this adds some context that I was missing. I'm currently trying to get my head into the WASI space and understand what's possible or practical. I'll check out spin-contrib-http and see how the approach might influence something like query string parsing.