<br><br><div class="gmail_quote">On Sat, Apr 10, 2010 at 4:41 AM, Peter Robinson <span dir="ltr">&lt;<a href="mailto:thaldyron@gmail.com">thaldyron@gmail.com</a>&gt;</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 &lt;<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>&gt; wrote:<br>
&gt; It&#39;s like you read my mind... I very consciously designed this in such a way<br>
&gt; that it would be possible to do this. More to the point: I think it would be<br>
&gt; possible to use web-routes-quasi to create a RESTful API and then<br>
&gt; auto-generate the basic API documentation. I&#39;d like to eventually figure out<br>
&gt; a way to support GET and POST parameters as well for this.<br>
&gt; Anyway, for the basic [String] methods, I can add support for it in the<br>
&gt; future; I&#39;d rather wait until we have the rest of web-routes settled down<br>
&gt; first.<br>
&gt; (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 -&gt;<br>
String), and the fields of the corresponding MyRoute constructors as<br>
parameters.<br>
<br>
- Wouldn&#39;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&#39;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&#39;t use Show that way.</div><div>* Usually, we&#39;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&#39;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&#39;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>