Strong conventions you say? Stop reinventing the wheel and build on top of REST. That would allow developers to define a resource and then have access to GET, POST, PUT, DELETE through an easy to use API.
In addition, we've been working with a bunch of really smart Rails people like Steve Klabnik and Santiago Pastorino on projects like ActiveModel::Serializers[2] and rails-api[3].
That being said, we know that there are a lot of different ways to serialize and transmit records, so we've designed the architecture of Ember Data such that those decisions are encapsulated in specific objects which we call adapters. You can think of it like the adapters for different databases for ORMs like ActiveRecord.
The default adapter, though, is RESTful JSON, and is what we use in all of our applications. You can see the implementation on GitHub[4].
1: http://emberjs.com/guides/models/the-rest-adapter/
2: https://github.com/rails-api/active_model_serializers
3: https://github.com/rails-api/rails-api
4: https://github.com/emberjs/data/blob/master/packages/ember-d...
This is from the first paragraph on backbonejs.com.
API over a RESTful JSON interface.
Emberjs.com doesn't mention REST once, not on the homepage, guides page, or API page.
Conventions are more than just HTTP verbs, and the REST you refer to is... a set of conventions!
If you look at the spec for, say, ATOMpub[1], you'll find a set of conventions on top of REST: "Here's how you retrieve a resource"[2], "here's how you edit a resource"[3], "here's how you delete a resource"[4], among other things. This is because (as I'm sure you know, since you care about REST so much) that HTTP verbs do not map directly to CRUD, and there are verbs that do other things as well, so it's important to say what we mean, exactly.
"Conventions" are just putting a little bit of formalism around communication, so that both parties know what's being discussed. That's _really important_, especially between back ends and front ends. When AM::S spits out conventions-based JSON (there isn't a good name for the format yet), I can be confident that Ember apps will understand what I'm talking about, and that relieves work I'd normally have to do.
1: http://tools.ietf.org/html/rfc5023
2: http://tools.ietf.org/html/rfc5023#section-5.4.1