<br><br><div class="gmail_quote">On Sat, Apr 10, 2010 at 4:41 AM, Peter Robinson <span dir="ltr"><<a href="mailto:thaldyron@gmail.com">thaldyron@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 6 April 2010 21:38, Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>> wrote:<br>
> It's like you read my mind... I very consciously designed this in such a way<br>
> that it would be possible to do this. More to the point: I think it would be<br>
> possible to use web-routes-quasi to create a RESTful API and then<br>
> auto-generate the basic API documentation. I'd like to eventually figure out<br>
> a way to support GET and POST parameters as well for this.<br>
> Anyway, for the basic [String] methods, I can add support for it in the<br>
> future; I'd rather wait until we have the rest of web-routes settled down<br>
> first.<br>
> (Of course, a patch is always welcome.)<br>
<br>
</div>Here are some more thoughts on the above point:<br>
<br>
The handler functions take the user supplied type, a function (MyRoute -><br>
String), and the fields of the corresponding MyRoute constructors as<br>
parameters.<br>
<br>
- Wouldn't it be simpler to automatically derive an instance of Show for<br>
the MyRoute type? (Since MyRoute is created on the fly anyway, I don't<br>
see why anyone would want to derive a different Show instance.)<br>
<br></blockquote><div>Multiple problems:</div><div><br></div><div>* The rest of web-routes doesn't use Show that way.</div><div>* Usually, we'll need another parameter to create this function, such as the application root.</div>
<div>* 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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- About the possibility of querying the supported methods: The use case<br>
scenario I have in mind is having a default handler for handling OPTIONS<br>
that returns the available methods. Currently this won't work since that part<br>
of the resource information is unavailable inside the handler. Do you have any<br>
thoughts on how to change the design to make this possible?</blockquote><div><br></div><div>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?</div>
<div><br></div><div>Michael </div></div>