Easy REST server w/o views or controllers?

ruby-talk
1

Hi all,

I'm in the processing of refactoring Puppet[1]'s networking, which currently uses xmlrpc over https but I'm moving to REST, and I'm hoping to be able to rely largely on existing code for the new work.

The weird situation with Puppet is that I'm only interested in computer-computer communication and in most cases have no interest in multiple forms of a given object, so I don't think I need views, and I'm not using a db backend, which means I don't need an ORM like ActiveRecord. Basically, I just need the controllers and routing, I think.

I've looked around at most of the frameworks I can find, including Nitro, Merb, Camping, and Rails, and all of them seem to assume that I care deeply about databases and HTML, while really all I want to do is make it easy to provide a REST-like interface for my software to use to talk to itself.

I plan on using ActiveResource[2] for the clients, and I'd love something that was just as easy but handled the server side for me. I've got 9 different namespaces in xmlrpc right now, but I want it to be easy to add new controller types, of course.

One of my biggest concerns with whatever I use is that it be easy to distribute, since Puppet runs on all popular platforms (e.g., os x, debian, ubuntu, rhel, fedora, solaris, freebsd) and is available as a native package in most cases. I don't want people packaging puppet to also have to package 10 other prerequisites, so I don't want to rely on something that brings in 50 libraries to handle views or models that I won't use.

Anyone have any experience writing something like this? Can anyone point me to an easy server-side REST api creator, something with few dependencies and that focuses on the routing? There are some things I've been told are in Rails that I'd also like, like content-type negotiation and automatic serialization and deserialization, since I'm sometimes passing YAML around (although often just plain text).

Thanks,
Luke

1 - http://reductivelabs.com/trac/puppet
2 - http://wiki.rubyonrails.org/rails/pages/ActiveResource

···

--
  Never esteem anything as of advantage to you that will make you break
  your word or lose your self-respect. -- Marcus Aurelius Antoninus
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

2

Luke Kanies wrote:

Hi all,

I'm in the processing of refactoring Puppet[1]'s networking, which currently uses xmlrpc over https but I'm moving to REST, and I'm hoping to be able to rely largely on existing code for the new work.

The weird situation with Puppet is that I'm only interested in computer-computer communication and in most cases have no interest in multiple forms of a given object, so I don't think I need views, and I'm not using a db backend, which means I don't need an ORM like ActiveRecord. Basically, I just need the controllers and routing, I think.

I've looked around at most of the frameworks I can find, including Nitro, Merb, Camping, and Rails, and all of them seem to assume that I care deeply about databases and HTML, while really all I want to do is make it easy to provide a REST-like interface for my software to use to talk to itself.

Interesting. One thing I like about Nitro is that it doesn't presume the use of a database. Model objects can be "enchanted" to magic persistence if needed, but otherwise they're just PORC. Og is not a requirement for a Nitro app.

Same for Ramaze (which is similar to Nitro, but more modular).

I plan on using ActiveResource[2] for the clients, and I'd love something that was just as easy but handled the server side for me. I've got 9 different namespaces in xmlrpc right now, but I want it to be easy to add new controller types, of course.

One of my biggest concerns with whatever I use is that it be easy to distribute, since Puppet runs on all popular platforms (e.g., os x, debian, ubuntu, rhel, fedora, solaris, freebsd) and is available as a native package in most cases. I don't want people packaging puppet to also have to package 10 other prerequisites, so I don't want to rely on something that brings in 50 libraries to handle views or models that I won't use.

Look at Ramaze.

···

--
James Britt

"The trouble with the world is that the stupid are cocksure and the
intelligent are full of doubt."
  - Bertrand Russell

3

You could use IOWA. It's pretty well self contained, doesn't really care what kind of content you are rendering, doesn't care what ORM you use, or if you use one, has REST support built into the standard dispatcher, and has a pluggable dispatching mechanism so that you can actually do whatever the heck you want with dispatching. And I've been using it on production code for quite a few years -- five and a half, now.

If you use IRC, stop in at #iowa on freenode. The most current released snapshot is at withruby.com/iowa, but I have another that I've promised people will get pushed to Rubyforge soon.

Kirk Haines

···

On Thu, 2 Aug 2007, Luke Kanies wrote:

The weird situation with Puppet is that I'm only interested in computer-computer communication and in most cases have no interest in multiple forms of a given object, so I don't think I need views, and I'm not using a db backend, which means I don't need an ORM like ActiveRecord. Basically, I just need the controllers and routing, I think.

I've looked around at most of the frameworks I can find, including Nitro, Merb, Camping, and Rails, and all of them seem to assume that I care deeply about databases and HTML, while really all I want to do is make it easy to provide a REST-like interface for my software to use to talk to itself.

4

Might try:

  http://seattlerb.rubyforge.org/rc-rest

T.

···

On Aug 1, 1:06 pm, Luke Kanies <l...@madstop.com> wrote:

Anyone have any experience writing something like this? Can anyone
point me to an easy server-side REST api creator, something with few
dependencies and that focuses on the routing? There are some things
I've been told are in Rails that I'd also like, like content-type
negotiation and automatic serialization and deserialization, since
I'm sometimes passing YAML around (although often just plain text).

5

I've looked around at most of the frameworks I can find, including Nitro, Merb, Camping, and Rails, and all of them seem to assume that I care deeply about databases and HTML, while really all I want to do is make it easy to provide a REST-like interface for my software to use to talk to itself.

I use camping all the time for little projects where I just want a
view of something. Never used a database with it at all. With
the views I guess you can render any kind of response you like.
I've done simple kinds of content type negotiation for
the same URL by just changing the suffix of the URL

Camping.goes :app

class Foo < R '/foo\.(\w+)'
  def get( ctype )

    % Do stuff

    case ctype
    when 'html'
      render :foo_html
    when 'txt'
      render :foo_txt
    when 'xml'
      render :foo_xml
    when 'yaml'
      render :foo_yaml
    default
      render :fourohfour
    end
  end
end

then

http://xtargets.com/app/foo.txt
http://xtargets.com/app/foo.xml
http://xtargets.com/app/foo.yaml
http://xtargets.com/app/foo.html

all get me the same data in with a different representation.

It may be better ( though I didn't do it ) to overwrite render
with your own implementation which checks content type

alias :render, :old_render

def render(api)
  if @ctype
    old_render "#{api}_#{@ctype}"
  else
    old_render api
  end
end

then just do
class Foo < R '/foo\.(\w+)'
  def get( ctype )

           % Do stuff
    @ctype = ctype
    render :foo
    
  end
end

···

--
Brad Phelan
http://xtargets.com

6

hey luke - how goes?

we are just starting a project that's going to use extjs for the entire front-end

   http://extjs.com/

and my plan is to do only controllers for the backend : basically 'json_output remote_method(json_input)' rpc style interaction. all business logic will be exposed as ajax methods taking json in and rendering json. not quite up your alley, but maybe we can compare notes...

also, at some point in the past, i made a small plugin that allowed any rails model to be fully rest-able via xml or yaml... i'll try to dig it up...

a @ http://drawohara.com/

···

On Aug 1, 2007, at 2:06 PM, Luke Kanies wrote:

Hi all,

I'm in the processing of refactoring Puppet[1]'s networking, which currently uses xmlrpc over https but I'm moving to REST, and I'm hoping to be able to rely largely on existing code for the new work.

The weird situation with Puppet is that I'm only interested in computer-computer communication and in most cases have no interest in multiple forms of a given object, so I don't think I need views, and I'm not using a db backend, which means I don't need an ORM like ActiveRecord. Basically, I just need the controllers and routing, I think.

I've looked around at most of the frameworks I can find, including Nitro, Merb, Camping, and Rails, and all of them seem to assume that I care deeply about databases and HTML, while really all I want to do is make it easy to provide a REST-like interface for my software to use to talk to itself.

I plan on using ActiveResource[2] for the clients, and I'd love something that was just as easy but handled the server side for me. I've got 9 different namespaces in xmlrpc right now, but I want it to be easy to add new controller types, of course.

One of my biggest concerns with whatever I use is that it be easy to distribute, since Puppet runs on all popular platforms (e.g., os x, debian, ubuntu, rhel, fedora, solaris, freebsd) and is available as a native package in most cases. I don't want people packaging puppet to also have to package 10 other prerequisites, so I don't want to rely on something that brings in 50 libraries to handle views or models that I won't use.

Anyone have any experience writing something like this? Can anyone point me to an easy server-side REST api creator, something with few dependencies and that focuses on the routing? There are some things I've been told are in Rails that I'd also like, like content-type negotiation and automatic serialization and deserialization, since I'm sometimes passing YAML around (although often just plain text).

Thanks,
Luke

--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama

7

Trans wrote:

Might try:

  http://seattlerb.rubyforge.org/rc-rest

These guys never sleep.

I say we change the name of the language from "Ruby" to "Seattle" and be done with it.

···

--
James Britt

"I often work by avoidance."
- Brian Eno

8

He he. Yea, but do they draw us pretty pictures?

T.

···

On Aug 1, 8:15 pm, James Britt <james.br...@gmail.com> wrote:

Trans wrote:

> Might try:

> http://seattlerb.rubyforge.org/rc-rest

These guys never sleep.

I say we change the name of the language from "Ruby" to "Seattle" and be
done with it.

9

> http://seattlerb.rubyforge.org/rc-rest

These guys never sleep.

I say we change the name of the language from "Ruby" to "Seattle" and be
done with it.

Seriously, they're putting something in the water up there or something.

···

--
Giles Bowkett

Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org