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
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?
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.
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