Enable 'type provider mode' using content negotiation

[TWolverson]

I appreciate that this project is very new and probably a number of things haven't even been thought about yet (all in good time!) but at a glance I don't see any way that a REST service is supposed to 'know' that it should return results in the expected type provider format. Therefore I suggest that a way of doing this would be through HTTP content negotiation, wherein the REST type provider passes an Accept header containing some special content type to indicate to the server that it expects results in type provider format. This would therefore be easy to switch on using an OWIN middleware component on the server, for example, and wouldn't affect the usefulness of the service for doing whatever job it is meant to do independent of creating type providers. This would then make the type provider library a useful way of making services self-documenting, while not limiting them to being consumed from clients that understand F# type providers

[tpetricek]

This sounds like a good idea. What would be idiomatic value for the Accept header, to follow best HTTP practices?

[TWolverson]

The answer to that question turns out to be somewhat more involved than I anticipated. As per RFC4288 discussing the registration of media types, I think at this time the best place for this to sit would be in the personal/vanity tree, denoted by prs.

Therefore my suggestion is that the appropriate media type would be application/prs.tpetricek.fsharp-type-provider+json. The RFC does imply that using a prs name requires registration with IANA - as you're the author I'd say it's your prerogative whether you'd like to do this under your own name. There do seem to be very few prs registrations on this list, so I'd wonder whether this is not commonly done.

Perhaps more research is required.