Rails - Oct 2008 - Using Rails purely as a RESTful web service (no or little HTML)

Given how easy it is to create restful webservices in Rails (well,
that''s an understatement), I''m wondering if anyone out there
uses it
purely for that? IE Using only XML/JSON, and not bothering with  HTML
view/stylesheets and the rest of it?

I ask, because I''m not particularly fond of the rails RHTML, and feel
I''d get a quicker result integrating a Rails webservice with a content
management system.

Thoughts/opinions appreciated

Thanks

Marcos

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Oct 14, 6:30 pm, Marcos
<marcos.scri...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Given how easy it is to create restful webservices in Rails (well,
> that''s an understatement), I''m wondering if anyone out
there uses it
> purely for that? IE Using only XML/JSON, and not bothering with  HTML
> view/stylesheets and the rest of it?
I did essentially this when I built the Mixx API, although I did use
*.rxml files to render XML output, and *.rhtml to render JSON. But,
that was a choice - you certainly don''t have to. I wanted very strict
control over the formatting of the output, so that was how I chose to
do it. You can easily render JSON in a controller like this, though:

render :json => {:foo => ''bar'', :baz =>
''blue''}.to_json

XML is just as easy:

render :xml => {:foo => ''bar'', :baz =>
''blue''}.to_xml

Does that help?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> I ask, because I''m not particularly fond of the rails RHTML, and
feel
> I''d get a quicker result integrating a Rails webservice with a
content
> management system.
I disagree but find the approach very interesting. What CMS are you
going to use? And how closely would you bind them? Would you use rails
for all db transactions, or just for specific business logic?

Would you maintain separate databases or adapt Rails to work with the
CMS db (possible, though to me that kind of thing always seems a
little kludgy) or the other way around?

I''m just curious. Feel free to tell me to go away if you want.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> I disagree but find the approach very interesting. What CMS are you
> going to use? And how closely would you bind them? Would you use rails
> for all db transactions, or just for specific business logic?
The reason I say this is that the kind of app I''d like to build
(accountancy app), clients would generally want it to be fully branded
and part of their website. If I used a CMS with a plugin (that''s
essentially a RESTful client) they could customise (Google says I
should spell that with a ''z''!) to their heart''s
content. Move menu''s
about, hide menus, completely change everything around. The
accountancy software itself would essentially be a web service, that
many different types of client could use. I suppose one could use
either an iframe (urgh) or some kind of lightweight proxy that just
goes as gets the HTML interface, with client specific stylesheet. But
I''m not sure that''s any better. (an added, but not
insurmounable,
problem in that case would be ensuring you had a continuations proxy
to support comet requests)

For the CMS (if I go this approach, big ''if'') it''s a
toss-up between
Drupal and Joomla. Drupal, for me, has the edge though - I just find
the way it works more logical. Plus it has a built in http-client
method. Not a biggie - but nice it''s there out of the box.

Basically, I just see you get so much for free with a CMS that clients
would love. Want a calender? No problem, install the module, choose a
place for it. Done in literally a few minute. I know Rails is fast,
but not that fast :) You can add loads of things so easily. Many
potential clients I know still use static web sites that they pay
someone just to add a news item, so they''d probably go with the CMS.
> Would you maintain separate databases or adapt Rails to work with the
> CMS db (possible, though to me that kind of thing always seems a
> little kludgy) or the other way around?
Essentially, the CMS would be a view/controller, and the rails web app
the model. I certainly wouldn''t want to keep any state in the local
CMS DB that was required in another client. I also wouldn''t want the
Rails web service to work with the CMS DB, chiefly because I don''t
necessarily want i on the same box, and would completely spoil the
independence anyway. I''d think of the CMS plugin as purely an client.
I could have other clients like a native app, an iphone app, even a
integrate with an Excel spreadsheet (urghh!!!). Essentially one should
be able to pick up any of those clients, and not see any difference in
the data. A bit like reading your IMAP email both in Thunderbird and
Google Mail. The only things in the CMS DB would effectively be the
the client settings.

As a sort of pros/cons, what do you think of this?:

DIrect Rails app

1) Better performance - you''re running one thing. Plus it would be on
one server - I expect HTTP requests would be significantly slower than
straight ActiveRecord/DB requests.
2) Simpler setup (using only one stack, no need for PHP etc)
3) No need to upgrade the ''client''
4) Fair easy stylesheet customization

1) Not as easy to customise menus, forms etc. Could add write this
functionality yourself, but would take time. There'' DRY, and then
there''s DRO (don''t repeat others :)
2) Harder to properly integrate into a clients website - or
3) Client must direct their users to a separate URL

Drupal + RESTful Rails app

1) Decoupling encourages a design that makes it easier to add other
clients
2) Can easily add CMS plugins to add standard functionality, of which
there are hundreds.
3) Much easier to customise. Say the client doesn''t want to see a menu
for x, because it''s not relevant. No problem - they could probably
even do it themselves. The accounting plugin would be the client''s app
- customised as much as they are willing to pay for.

1) All these client customisations could be nightmare to manage
2) New or changed features could break clients
3) Would be technically slower - they question is would it be slower
on the human scale (ie 100ms might be ten time as slow as 10ms, but
it''s still only 100ms)
4) More loads on the server - assuming the CMS is on the same server.
5) More complex setup
> I''m just curious. Feel free to tell me to go away if you want.
Quite the contrary - very happy someone''s taken an interest! Happy to
hear any opinions.

Thanks

Marcos
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---