Build on top of OWIN with Agent Routing #16
Conversation
…r than a content file.
| // TODO: Create a ResourceManager or some form of Supervisor to serve as the App. | ||
| // Example: | ||
|
|
||
| type App () as x = |
There was a problem hiding this comment.
Generalize this into a Supervisor type. This could implement IDictionary<string, Resource> to provide a somewhat similar API to the suggested type provider.
In order to make this work, I will need to build an internal DSL to mimic the route specification. Something like the following might do:
type UriSegmentTemplate = string // Possibly something more complex
type RouteDef = UriSegmentTemplate * HttpMethod list
type RouteSpec =
| RouteNode of RouteDef * RouteDef list
| RouteLeaf of RouteDef
// Need a module to recurse this tree, create Resource instances from RouteDefs, and hook them to their Supervisor.
|
|
||
| /// Defines the route for a specific resource | ||
| type RouteDef<'T> = 'T * UriRouteTemplate * HttpMethod list | ||
|
|
There was a problem hiding this comment.
I've implemented the proposed RouteDef and RouteSpec as a data structure for communicating intended routes. The current implementation uses a discriminated union to strongly type access to the routes and a simple string for specifying route templates. The route templates are composed as the tree is composed.
| let app = new ResourceManager<Routes>(spec) | ||
| let resource = app.[Root] | ||
| do resource.SetHandler <| get helloWorld | ||
| do resource.SetHandler <| post echo |
There was a problem hiding this comment.
Example of configuring Resources with the ResourceManager.
|
Does it make sense to put this here or in dyfrig? |
|
I pulled this out as a separate project to determine how well it might work as a framework agnostic library. See the current status at the Taliesin project. My chief concern is that it uses a lot of generics. Extension interfaces would really help here, as would a true type provider, though I don't know how a Type Provider would adapt to framework types. |
This is a shift in thinking from being buddy-buddy with Web API to simply using System.Net.Http types.
Benefits:
Cons:
To really work, this needs a type provider for the routing. However, I can implement a close approximation, which is in progress in this commit.
Note: not all the samples work.