Accept header based routing

[jason-johnson]

Related to issue #1654

I am trying to create a crate as described in that discussion (gist is here). The strategy works to route based on the content type but one problem is that this crate is doing RFC compliant negotiation of the Accept header vs. what the server can produce but does not have a way to pass the resulting media type to the handler or to set the content type. I modified the call function to set the content-type header but he handler still needs a way to see it because it may chose different rendering based on this negotiated media type (e.g. a type with a json subtype). Of course the handler could simply use an extractor to get the Accept header and do the negotiation but that would be a shame since the MediaTypeHandler crate is already doing that.

[jplatte]

I'm sorry but I'm still not at all following.

It sounds like you're not interested so much in supporting multiple input formats, but only multiple output formats, is that much correct?

Can you show an example snippet of how the API you've written so far would be used?

[jason-johnson]

But in any case, I realized this morning that probably the Or handler is enough with no additional stuff. I just need to define a suitable extractor that will negotiate the header.

[jplatte]

Then what does the Accept header have to do with it? That's for the client telling the server which response body formats it understands.

[jason-johnson]

Exactly. Because the client may only understand version 1, so we'd need to run the version 1 handler to return it something it understands. If it understands version 2 or both versions then we can run the version 2 handler and send the newer one.

[jason-johnson]

Oh! I just realize, you are correct: I'm only concerned with the output I need to run. I can already deal with inputs with the existing axum infrastructure, no need to involve routing for that I believe.

[jason-johnson]

I had thought I was talking about "input" because it is what comes into my function and not "output", what my function produces.

In any case, just creating a negotiating extractor, as shown here, completely does the routing when combined with or, nothing else needed. The same trick would work with content-type input routing but I wonder if this wouldn't be a better solution.

If I end up adding AcceptLanguage negotiation then I will probably release the gist above as a crate but unfortunately there isn't an existing negotiation implementation I could use. But maybe this would be enough.