[web-devel] web-routes-quasi

Michael Snoyman michael at snoyman.com
Sun Apr 11 01:00:06 EDT 2010

On Sat, Apr 10, 2010 at 4:41 AM, Peter Robinson <thaldyron at gmail.com> wrote:

> On 6 April 2010 21:38, Michael Snoyman <michael at snoyman.com> wrote:
> > It's like you read my mind... I very consciously designed this in such a
> way
> > that it would be possible to do this. More to the point: I think it would
> be
> > possible to use web-routes-quasi to create a RESTful API and then
> > auto-generate the basic API documentation. I'd like to eventually figure
> out
> > a way to support GET and POST parameters as well for this.
> > Anyway, for the basic [String] methods, I can add support for it in the
> > future; I'd rather wait until we have the rest of web-routes settled down
> > first.
> > (Of course, a patch is always welcome.)
> Here are some more thoughts on the above point:
> The handler functions take the user supplied type, a function (MyRoute ->
> String), and the fields of the corresponding MyRoute constructors as
> parameters.
> - Wouldn't it be simpler to automatically derive an instance of Show for
> the MyRoute type? (Since MyRoute is created on the fly anyway, I don't
> see why anyone would want to derive a different Show instance.)
> Multiple problems:

* The rest of web-routes doesn't use Show that way.
* Usually, we'll need another parameter to create this function, such as the
application root.
* Show is usually the inverse of Read. I suppose we could make the Read
instance the other side, but that we're just not following what is normally
expected of these instances, which is to return Haskell-formatted data.

- About the possibility of querying the supported methods: The use case
> scenario I have in mind is having a default handler for handling OPTIONS
> that returns the available methods. Currently this won't work since that
> part
> of the resource information is unavailable inside the handler. Do you have
> any
> thoughts on how to change the design to make this possible?

Well, the simplest thing I can do is make the [Resource] result from the
quasi-quoting available, which would give you enough information to write
something to intercept OPTIONS requests before handing them to the rest of
the application. Does that sound good enough?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100411/cea6f0d6/attachment.html

More information about the web-devel mailing list