Ian, Nice write-up. Thanks.
We use a Rails app for our JSON API’s. A few years ago, the predecesor to the product was a Sinatra app, that eventually became almost Rails. Thus, Rails was chosen for the re-write (this was before my time at the company). I have heard many anecdotes of people starting out with a lighter-than-Rails option for an API, that eventually pulled in a lot of Rails stuff. If I was starting a brand new API tomorrow I would do what you suggest: Choose Rails, tweak the Gemfile (i.e., remove turbolinks and jQuery) and go on my merry way. — Ylan Segal [email protected] > On Jan 21, 2015, at 12:07 PM, Ian Young <[email protected]> wrote: > > 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. -- -- 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.
