On Dec 17, 2007 7:22 PM, snacktime <snacktime at gmail.com> wrote:
> Thought I''d give some feedback after using unicycle.
>
I should admit that one of my hesitations in releasing Unicycle as a
general-purpose REST framework is that it''s currently married to
EM''s HTTP
server. If we can make it work with Webrick, Apache, etc., it would probably
be of more general interest. Of course, there are good reasons to keep the
strong linkage to EM no matter what else we add: performance for one, and
concurrency based on Deferrable for another. The latter capability in
particular would allow Unicycle to fill a major gap in Ruby web-framework
offerings, which is servers that require data from other servers.
>
> - I added attr_reader :http_request_uri to Unicycle::Protocol, I
> needed it and I think it''s handy to have available in the handler.
Do all of these that you want. :-)
>
> - Ability to set the response code, especially for REST. I changed
> the behavior of the handlers so they return a response code and
> response text, and changed fulfill_request accordingly.
I think there already is a way to do that in the @response object. Also, if
you simply raise a Ruby runtime error in any Unicycle handler, it
automatically returns a 500 error to the client with the exception text in
the response body.
The return value from a Unicycle handler is a little baroque, which is why
I''d be hesitant to change it. In addition to a String or a Deferrable,
you
can return the special code :continue, which will invoke the next handler in
a chain.
> - Some REST resources have id''s nested in the uri, a convention
for
> supporting this would be nice. For example, /videos/50/format/flash.
> Maybe the router could recognize certain tokens in the url handler
> definitions, something like so:
>
> rest {
> url "/videos/ID/format/flash"
> handler Videos
> }
>
> The parser could allow any alphanumeric (or user defined regex) string
> for ID, and place occurences of ID into @url_params or something
> similar.
>
That''s a very interesting idea. Up until now, I''ve fudged
around it by
defining my REST handlers so that any parameters are tacked on to the end of
the URL, which isn''t always ideal. Also, there''s another
important REST
technique, which is selecting different output formats (HTML, JSON, XML,
plain text, etc) based on the Accept header. None of that is done yet.
>
>
> - Might be nice to change the router so you can put multiple
> url/handler combinations within one rest{} block. Ok that''s a bit
> picky I know...
That''s there now. In fact, I use that feature in my code to handle
auth/az
and sessions.
>
> - support for json content type.
How might that work?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071218/96312885/attachment.html