full rest framework?

[Francesco Zanitti]

Hi,
in these days there's something in my mind: ryan is being shaped like
a "standard" web framework up until now, am I right? I mean, the
philosophy behind ryan is roughly the same as, ie, rails, am I right?
what about implementing also a full rest framework? it can be a layer
above webmachine, for example, or even write something similar
directly in reia. I was also thinking about a way of persisting reia
object, something written in the language (I think that this shouldn't
be a really hard-to-have feature) -- but this is to be asked to
tony :) . I don't have much time to think about these things, but
roughly the idea was to use ryan + reia + mnesia (+ tokyo cabinet or
similar to overcome the 2gb mnesia limitation) to build rest
webservices, what do you think?

cheers,
fz

[Tony]

On Thu, Mar 26, 2009 at 10:46 AM, Francesco Zanitti <fzan...@gmail.com> wrote:

Hi,
in these days there's something in my mind: ryan is being shaped like
a "standard" web framework up until now, am I right? I mean, the
philosophy behind ryan is roughly the same as, ie, rails, am I right?
what about implementing also a full rest framework? it can be a layer
above webmachine, for example, or even write something similar
directly in reia.

Personally I'd like to see something like Rack (e.g. pluggable backends, letting you register multiple applications and their associated routes), but that can wait until people are actually writing webapps.
 

I was also thinking about a way of persisting reia
object, something written in the language (I think that this shouldn't
be a really hard-to-have feature) -- but this is to be asked to
tony :)

I think what you might accomplish elsewhere with object serialization can be accomplished in Reia by just keeping the objects (i.e. processes) running persistently.  In the future you'll be able to create a supervisor to automatically bounce them when they crash.

I've had a few requests for an object serialization mechanism but I'm not planning on implementing one any time soon.

--
Tony Arcieri
medioh.com

[Phil Pirozhkov]

Hi

All over the net you can find claim that rest is bad.
"Everything you need to do can be done with GET, PUT, POST, and DELETE.
The beauty of REST is that those four verbs are all you need."
Not true.
I currently need "get", "put", "update" (post), "delete", "undelete", "suspend", "resume"
i have to add additional parameter :command and REST ends up here.

Not all browsers support that four correctly.
Pushing "back" after "POST" works ugly in Safari and Firefox.

You can still have you controller initialized with @method, and
treat it however you like.

But it's way easier to change the code on client side:
<form id=list method=delete action=/users/1 ...

to
<form id=users method=post action="/users/delete/1 ...

than that router mess on server side

Helpers always help:
#users
link_to(:user, :id, :delete)

or something similar

and just add a corresponding method to your controller

class Users
def delete
user = User.find(@params[:id])
user.drop()
end


But i'm sure "router" can be easily transformed to conform REST (it's currently nine code rows)


Cheers, Phil

[Francesco Zanitti]

On Mar 27, 2009, at 9:06 AM, Phil Pirozhkov wrote:

>
> Hi
>
> All over the net you can find claim that rest is bad.
> "Everything you need to do can be done with GET, PUT, POST, and
> DELETE.
> The beauty of REST is that those four verbs are all you need."
> Not true.
> I currently need "get", "put", "update" (post), "delete",
> "undelete", "suspend", "resume"
> i have to add additional parameter :command and REST ends up here.

I'm aware that the rest principles just doesn't work every kind of
software projects (anyway "REST" != get/post/put/delete, if you think
of webdav you'll see that it is rest, what is expanded is the http
protocol itself). And note that here I do not refer to web
applications, but to web services (so the client doesn't needs to be a
web browser --we all know that ie. you just can't use 'delete' as a
form method--).

anyway, you can model all of the methods you listed as separate
resources, ie "undelete" can be a post to a undelete resource with an
identifier of the deleted resource, suspend and resume can be
associated to a resource to post to, which accept the already
mentioned identifier. (yeah, overloaded post here :) )
Sorry, I just don't want to start another useless flame war, I know
that especially for web application it is difficult to model
application states only using resources, and there are cases in which
rest simply doesn't fit.

>
> Not all browsers support that four correctly.
> Pushing "back" after "POST" works ugly in Safari and Firefox.

sorry, didn't got this one xD

>
> You can still have you controller initialized with @method, and
> treat it however you like.
>
> But it's way easier to change the code on client side:
> <form id=list method=delete action=/users/1 ...
>
> to
> <form id=users method=post action="/users/delete/1 ...

indeed :)

>
> than that router mess on server side
>
> Helpers always help:
> #users
> link_to(:user, :id, :delete)
>
> or something similar
>
> and just add a corresponding method to your controller
>
> class Users
> def delete
> user = User.find(@params[:id])
> user.drop()
> end
>
>
> But i'm sure "router" can be easily transformed to conform REST
> (it's currently nine code rows)

I'll have a better look to the code (I'm quite new to reia itself --
even to erlang itself)

>
>
> Cheers, Phil

best,
fz

[Phil Pirozhkov]

I'm open to "there's a task to do the following... How do i better do that with Ryan?"
I'm sure there will always be a simple solution to anything.

Since browsers are one of the most advanced web service consumers, and web servers
provide web services (it isn't described with wsdl and is not forced to be xml and
that's a plus), assume that Ryan is a nice backend for web services using any protocol
built on top of HTTP. And Ryan itself only knows HTTP and i don't see any need to
include soap/wsdl/xml-rpc/rest stuff in core package.

I'm currently working on web server abstraction at the moment, something like Ruby's Rack,
just like Tony mentioned. It should work fine with YAWS/Mochiweb, probably Inets for guys
who don't want to install YAWS/Mochiweb on a developer's machine (i never wanted, too! :)

Phil

[Francesco Zanitti]

On Mar 27, 2009, at 3:57 PM, Phil Pirozhkov wrote:

>
> I'm open to "there's a task to do the following... How do i better
> do that with Ryan?"
> I'm sure there will always be a simple solution to anything.
>
> Since browsers are one of the most advanced web service consumers,
> and web servers
> provide web services (it isn't described with wsdl and is not forced
> to be xml and
> that's a plus), assume that Ryan is a nice backend for web services
> using any protocol
> built on top of HTTP. And Ryan itself only knows HTTP and i don't
> see any need to
> include soap/wsdl/xml-rpc/rest stuff in core package.

ok, I think I'm going to dig deeper with this on my own, really what I
have in mind is a way to remove frameworks, not to add layers and
layers of (useless) hhhumm.. "over engineered" stuffs xD !

>
> I'm currently working on web server abstraction at the moment,
> something like Ruby's Rack,
> just like Tony mentioned. It should work fine with YAWS/Mochiweb,
> probably Inets for guys
> who don't want to install YAWS/Mochiweb on a developer's machine (i
> never wanted, too! :)

I can only say..keep up the really good work :D !