This is an ongoing area of interest for me. The way things are currently going in web development, I think those of us who want to continue doing backend work with Ruby should get very comfortable building JSON APIs, since that's one place where the demand is definitely not going to dry up.
Like John, I've built an API on the standard Rails stack and it has been fine. We just removed all the frontend and asset gems from our Gemfile and left it at that. I think the performance concerns around having extra code running are probably a bit overstated. That said, Rails::API sounds nice and if you're dedicated to going API-only you probably might as well go with that. Of course, every API will end up evolving a need for a couple pesky HTML pages (like, for example, your side of the authorization flow if you're doing OAuth). So then you have to decide how to handle those: do you keep them in the same app, thus loading up all those frontend dependencies you were trying to avoid? Or do you go with the more architecturally clean solution of putting them in a separate service and deal with the extra development overhead that brings? I've also built an API in Padrino and found that fairly pleasant. Padrino hits a nice sweet spot of being extensible enough to handle a fairly large application, plus coming with a lot of the niceties that we're used to from Rails land (like generators and an interactive console), but offering more fine-grained component selection than Rails. Particularly nice for this case is that the Padrino project generator has flags that let you include or exclude whole chunks of functionality, like assets, frontend, or test frameworks. All that said, I don't feel particularly fervent about using Padrino over Rails. The more of the Padrino app I build, the more gems and bits of ActiveSupport I pull in, and the closer it gets to resembling the Rails stack. I think the end result tends to converge, regardless of how you start. I've been wanting to use Grape, as it looks like a nice way to handle a lot of the typical API stuff. I also like that it exists as a Rack app, and thus should be mountable in any framework. Airborne looks cool too. I've been using json_expressions, which perhaps offers a bit more flexibility, but I might choose airborne next time for the simplicity of it (and because json_expressions is only lightly maintained). I also feel that there are several common problems in Rails API building that aren't yet adequately solved. Powerful semantic matchers for testing JSON results is one. Another is cleaning up the noise of sending every request in tests with proper Accept headers, OAuth token headers, etc. I have like 50% of a solution for this one, and should really take the time to make a proper gem out of it some day. Another problem I've had (unless I was just doing something terribly wrong) is that it's remarkably hard to convince Rails to respond only to requests with an Accept: application/json header, and to 406 everything else (I know it looks easy, but there are edge cases and loopholes). I'd love to see some more tooling focused on the specific needs of building and testing JSON APIs. It ought to be as easy and fun as the other standard Rails use cases. So if you're interested in talking about this or have ideas or know of existing projects I should look at, hit me up. I'd love to hear about it. On Sun, 2015-01-18 at 16:10 -0800, Michael Cordell wrote: > I've used Grape in Sinatra apps and have liked the DSL it provides for > defining APIs. Further, it makes things like documenting the API > simple. I think its definitely worth a look. > > > > Regardless of what you chose, you should also definitely look at > airborne gem for testing the API. It is built on Rspec and provides > convenience methods/helpers for API testing. > > > > > Michael > > > > On Sunday, 18 January 2015 13:09:41 UTC-8, kenglish wrote: > > @benwanicur I would always favor using Rails as it provides > such great > routing and controller facilities. I know some people that > have used > Grape (https://github.com/intridea/grape) with some success. > > I came across this post this week: > > http://www.leighhalliday.com/posts/responding-with-json-in-rails > > The only of these that I wasn't aware of was ROAR which > actually looks > like a nice approach. > > Kevin > > On Sun, Jan 18, 2015 at 12:02 PM, Cynthia Kiser > <[email protected]> wrote: > > I haven't used it yet but this Ruby Rogues episode has me > quite > > interested in Padrino - especially for things like API > apps. > > > > > > http://devchat.tv/ruby-rogues/170-rr-padrino-with-dario-cravero-nathan-esquenazi-arthur-chiu > > > > > > > -- > > Cynthia N. Kiser > > [email protected] > > > > -- > > -- > > SD Ruby mailing list > > [email protected] > > http://groups.google.com/group/sdruby > > --- > > You received this message because you are subscribed to the > Google Groups "SD Ruby" group. > > To unsubscribe from this group and stop receiving emails > from it, send an email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > -- > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > --- > You received this message because you are subscribed to the Google > Groups "SD Ruby" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
