5 ms·
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,
by anonfunction 14y ago
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.
- spellboots 14y agoEmber data is built on top of REST.
- anonfunction 14y agoThat's good to know... though in my hasty research I didn't see anything that said so. That should be a big selling point. https://github.com/emberjs/data https://github.com/emberjs/data
- MrMcDowall 14y agoI've submitted a PR to em-data which should make the REST support a bit more clear. https://github.com/emberjs/data/pull/834 https://github.com/emberjs/data/pull/834
- tomdale 14y agoThanks for the suggestion! In fact, you've just described exactly what we're building. We are big fans of REST, and if you read the documentation, you'll see that the default behavior of Ember Data is to transmit RESTful JSON[1]. 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/ http://emberjs.com/guides/models/the-rest-adapter/ 2: https://github.com/rails-api/active_model_serializers https://github.com/rails-api/active_model_serializers 3: https://github.com/rails-api/rails-api https://github.com/rails-api/rails-api 4: https://github.com/emberjs/data/blob/master/packages/ember-data/lib/adapters/rest_adapter.js https://github.com/emberjs/data/blob/master/packages/ember-d...
- anonfunction 14y agoThanks for the response! Only reason I mentioned it was that I didn't see REST anywhere in the linked article or here: https://github.com/emberjs/data https://github.com/emberjs/data
- anonfunction 14y agoI don't understand the downvotes. 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.
- steveklabnik 14y agoAM::S maintainer here! 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 http://tools.ietf.org/html/rfc5023 2: http://tools.ietf.org/html/rfc5023#section-5.4.1 http://tools.ietf.org/html/rfc5023#section-5.4.1 3: http://tools.ietf.org/html/rfc5023#section-5.4.2 http://tools.ietf.org/html/rfc5023#section-5.4.2 4: http://tools.ietf.org/html/rfc5023#section-5.4.3 http://tools.ietf.org/html/rfc5023#section-5.4.3