Leveling up / proposal

[glennblock]

Let's level up for a second.

We talked about just starting with a way to reuse hypermedia libraries across web stacks and clients. So ideally I could use CJ (my library), Uber, HAL, and JSON API with whatever client / server I choose.

So.....

We need the following to fulfill that goal.

• A reader/writer for handling the body.
• A piece of OWIN middleware that can use the reader/writer. This will address all server scenarios.
• A custom HttpContent class that uses the reader/writer. That will address scenarios using the .NET HttpClient. Could also do a Web API Client formatter here as that is client only / not pulling in the server.
• A Rest Sharp bridge for the reader/writer. This will address scenarios using Rest Sharp as the client.
• An implementation of the reader/writer for CJ, HAL, Uber and JSON API.

If we start here without going deeper, we end up with reuse of these hypermedia libraries across client and server frameworks

[glennblock]

Adding @panesofglass to weigh in from the OWIN side. Ryan and I just skyped for a bit. It sounds like it is achievable via OWIN middleware, but it does raise a couple of questions.

OWN is based on a set of Request and Response dictionaries (surfaced as the env [environment] variable. It doesn't know anything about passing objects around etc.

However, you can add specific keys to the env dictionary. So we could have a piece of OWIN middleware that looks for a specific key in the response env for writing out the content. On the read side, it could set a specific key in the OWIN request env.

At the framework level (Nancy, ASP.NET vNext, Web API) it would then need to get access to the OWIIN request / response to handle retrieving or writing back an object.

This is the conceptual, the devil is in the details.

An alternative way is to have specific implementations at the framework level that work directly with the response, i.e. IResponseProcessor for Nancy, or MediaTypeFormatter for web api etc, but it doesn't seem ideal.

To make things a bit more complicated, there's the question of conneg. Currently, conneg is handled at the higher level within a framework, there doesn't seem to be a general purpose conneg middleware for OWIN, though one could be built (should be built)?

[glennblock]

Adding @wis3guy to weigh in as well.

[glennblock]

For conneg, Nancy has a nice implementation. I think it could be refactored to be Nancy agnostic / a new project born based on its code and then used either as a piece of middleware or within a framework / app.

[glennblock]

One idea for the client, is we just reuse the OWIN request/response abstractions on the client. There's nothing preventing from doing that I don't think. Then you would just need adapters for going from OWIN to either the .NET HTTP abstractions or RestSharp abstractions.

A lot of thinking out loud here I know! It's @wis3guy's fault for getting the juices flowing.

[glennblock]

@danbarua @grumpydev pulling you guys in as well.

[wis3guy]

@glennblock I'm sorry for not responding earlier. December is a tricky month for me to work on these projects due to inevitable deadlines/deliveries and pre-holiday work-stress, hence the infrequent contributions.

To be frank, I'm not 100% sold on pushing this into the middleware. Even if it is in theory possible. It seems to me that this will incur (much) more work than would it be, if we simply leverage the available/proven framework specific hooks (IResponseProcessor for Nancy, or MediaTypeFormatter for web api).

As you said, your suggested approach dictates we deal with concepts like conneg ourselves, while it is already in the framework that the API developer decides to use, yielding potentially unexpected (for the api developer) results. This just feels (subjective!) like a hack to me. Also, perhaps less of an issue, but we would be doing the framework's default work (formatting) yet ignoring the results, as we cannot turn such features off in the frameworks themselves.

Regarding the reuse of existing libraries, i'm in doubt that goal is achievable, without slightly modifying each one of them. Be it for calls from within a new middleware layer, the framework hooks or a client library. There should be some common contracts across libraries, right?

My preference would still be to embrace whatever the frameworks offer us, and simply agreeing on an abstraction for the reading/writing the responses. For clarity, my proposal took it one step further, converting into an intermediate formate, which is not 100% necessary.

Would you embark on a OWIN based spike, i'm eager to pitch in. At this point, though, i would not know where to start.

[danbarua]

^ you've basically put into words my feelings on the matter too, +1.

[panesofglass]

I hesitated to chime in earlier, as @glennblock mentioned most of what we discussed. Thinking about this months later and having worked on a web machine implementation for .NET, I think I would agree that a middleware-based solution would be tricky and probably difficult to use correctly.

This makes me wonder if we should be looking at changes to the OWIN signatures to provide better keys or additional hooks for staging HTTP transitions like conneg. If you have ideas, please submit them to https://github.com/owin/owin.

In any case, @kolektiv and I are trying to extend the web machine model with hypermedia and conneg, and we'd like to leverage your work. This is still early days for us, but I wanted to chime in that we are following the work over here.