Me too. There's nothing concrete here yet, but there's lots of space to explore and good things to build. I really want us to be a leader in this space.
I'm very excited about this as well. Any hints about what's on the roadmap?
Would love to see easy versioning with custom mime types and link headers for pagination and associated resources. Maybe that doesn't belong in core... but it would still be pretty cool.
My testing shows that versionist works just fine with rails-api apps to provide versioning capabilities. If you run into any problems, please file an issue.
Nothing specific so far. AMS should know how to put out some kind of hypermedia-enabled type. We want to build a bunch of apps and then pull an implementation out, not imagine what we think would be good and then try to build apps with it.
The organization includes ActiveModel::Serializers, which is really important for giving you normalized JavaScript output. Rabl is slow and manual, which is the opposite of the Rails philosophy. Convention over Configuration wins every time.
Basically, as it stands, you have to put your {Ember,Backbone,..} app in `app/assets/javascripts/app/models`, for example, which is kinda crazy. I'd like to see JavaScript become an actual first-class citizen.
Also, the pipeline has been re-written for Rails 4, but historically it's been kinda slow and buggy.
For an example of what I'm thinking about, rake-pipeline-web is interesting.
The problem with benchmarks is that they don't really correspond to reality. Your app is not a simple test app. Your site will not be running on my MacBook Air. Your users won't have the usage patterns my script does.
IMO you shouldn't do the benchmark. Let this project be a starting point for a Rails api project and/or a how to for people who want to customize Rails for their needs.
"We are building an API. Rails has extra components which aren't used but might cause overhead. Here is how to remove it."
Of course. It's not about showing some absolute numbers that users can expect. It's just about showing the potential overhead of a full Rails app vs Rails::API. I'd think this would be a reason why people would chose Rails::API over just Rails.
The README itself says Rails::API is faster, so not sure why a simple benchmark to back that up isn't a good idea.
edit: It really boils down to another way to visualize the overhead vs just listing what's been removed.
> Does the hypermedia support exist now, or is that a future goal?
Future goal. There's nothing at the moment, but it's a case that we're interested in. I'd love to talk about exactly what we need to do on the mailing list.
> Also, LOL at steveklabnik2 ;)
Yeah, steveklabnik would still be almost in top 100 to this day, I just looked. Sigh.
This has come at a time I'm looking at Grape mounted in a Rails app for an API layer. Is there a simple way to explain to those of us with less API building experience what the pros/cons are of using rails-api over something like the Grape gem?
Just the link would have been nice, I'm not jumping on raiks api right away, but skimming the getting started guide of something new usually helps me figure out if I want to use it or not in the future.
So sorry about this. I was travelling back from Europe, and we had to coordinate between everyone who owned the various gems, so there was a bit of overlap there.
I hope to not be encouraging people to use HEAD soon.
This is not a fork of Rails, it's just a set of plugins that work together nicely. Luckily, all the work on Rails 3 means that Rails is super modular, and it's easy to break off just the bits that you want. See Crafting Rails Applications[1] for more on this topic.
> The Hypermedia stuff is most exciting to me,
Me too. There's nothing concrete here yet, but there's lots of space to explore and good things to build. I really want us to be a leader in this space.