Wouldn't this be better as a new lightweight generator for the existing rails project? i.e.<p>$ rails new api<p>instead of<p>$ rails new<p>My concern is that rails-api will diverge from rails and I'll be stuck having to decide which is the easiest starting point where I want features from both.
A few days ago I found myself getting a rather strange git error while running bundle after upgrading to the latest ruby. Turns out the active record serializer gem was moved just hours earlier to this rails-api location without any reason or notice. It was referenced by a git revision, because we needed the latest changes and it was also encouraged in the readme (as it still is now).<p>My issue with all this is that we already had tagged revisions in our application and this basically broke our older builds on which we actually relied on should things go wrong (the application is a rails engine).<p>So I think it would had been nice if this was announced earlier.
I'm not trying but be harsh but I've never really understood the need for this project. I mean, Rails just boils down to a collection of gems right? So wouldn't you be best just cherry-picking your own gems? Or using something barebones to begin with, like sinatra/padrino?
Seems like a great initiative. As a django user, I was using tastypie, which sits on top of django for creating an API. I agree that it's nice to reduce some fat, if it's really not necessary.<p>On a side note, and sorry for going off-topic, but referring to this comment<p>> Security: Rails detects and thwarts IP spoofing attacks and handles cryptographic signatures in a timing attack aware way. Don't know what an IP spoofing attack or a timing attack is? Exactly.<p>It's not completely transparent to developers, or it shouldn't be. If you're not careful, your rails app <i>might be</i> vulnerable to IP spoofing even now.<p>See <a href="https://github.com/rails/rails/pull/7980" rel="nofollow">https://github.com/rails/rails/pull/7980</a> and <a href="http://blog.gingerlime.com/2012/rails-ip-spoofing-vulnerabilities-and-protection/" rel="nofollow">http://blog.gingerlime.com/2012/rails-ip-spoofing-vulnerabil...</a>
We're using this to build internal services - I'm currently wondering if there's a best practice for taking querystring params and mapping them to an ActiveRecord query.<p>Obviously, it's possible to build a "Searchable" module/class, but I wondered if anyone has already solved this problem?<p>Eg, pagingation, querying on date-ranges, ordering, filtering etc.
Does the hypermedia support exist now, or is that a future goal? I couldn't tell from your blog post whether the use of future tense "will" about most of the features implies "when you use it" or "when we write it" ;)<p>I also didn't see much in the READMEs or open issues having to do with hypermedia at a quick glance.<p>Also, LOL at steveklabnik2 ;)
I've built quite a few Rails-based APIs recently, and one of the major pain points (for me) has been the performance of generating the actual JSON in the payloads. I've ended up with a modified JBuilder gem and using a subset of its render methods, but performance is still pretty lack-lustre. Compared to to_json, it's absolutely glacial!<p>I'm wondering how the serialization in rails-api performs in this regard? I'm assuming as this is a core part of its differentiation from rails base, and so it should be better than JBuilder. Has anyone run any benchmarks for JSON rendering?<p>Forgive me if this is a naive question, this is the first I've heard of rails-api and I haven't explored the source or tried it out as yet.
We'll be taking this for a spin. I've been pushing for an API-driven site for awhile but the case for that model was cinched when we started adding non-web clients to our system.<p>A leaned-out Rails is a nice compliment to other bolt-on API options and fat GUI-based API builders. Personally I prefer to start with something even simpler, but the facts are you can cover more ground faster (and potentially safer) with something like this vs. building your HTTP stack from scratch.<p>The Hypermedia stuff is most exciting to me, as hand-rolling that is a hard-sell for many teams (if you have a system of any significant richness).
What's the easiest way to make this work well with the asset pipeline assuming I wanted to make a single page app hosted in the same project? Or should I just not do that?<p>edit: thanks, guys!
We've had a lot of love recently for Goliath + Grape, e.g. see: <a href="https://github.com/postrank-labs/goliath/blob/master/examples/grape/server.rb" rel="nofollow">https://github.com/postrank-labs/goliath/blob/master/example...</a><p>Goliath is it's own asynchronous app server, and it wraps around the nice Grape API DSL. Works really well for little projects I'd rather write in ruby than CoffeeScript + node.js
This looks great - I'll be trying it out for a project this week.<p>I'm still searching around for a good solution to API "views" or presenters when I don't want to expose all of a model's attributes. Something like Rabl? What do other people use?
Rails-api isn't a new project, and the name of the project is misleading. It provides a no-frills controller. Why is this is another project and not part of actionpack?
Whoa whoa whoa guys, timeout! I thought Rails enforced REST conventions on all your models and therefore Gives You An API For Free? Wasn't that its big selling point? Or of adhering to REST in general?