I recently encountered an interesting problem while sketching out a RESTful API for a side project with the JSON API specification. I’m definitely not the first person to run into this problem, but it ended up being a great thought exercise for designing APIs and better understanding the client-server relationship. Read more on Leveraging the Boundary Between Client and Server in a REST API…
Ember Data has strong opinions on how it wants you to structure your data and your API, which are essentially collapsed into one by its default paradigm. If you are using
ActiveModelSerializer, the path of least resistance is to have your
DS.Model classes essentially mirror your ActiveRecord classes, to the point where I feel like an Ember Data app is often doing SQL over AJAX.
I’ve previously blogged about DropWizard, a Java web framework for developing RESTful web services.
One of Dropwizard’s great features is its ability to easily write and deploy runtime administrative tasks for you application. Read more on Using Hibernate DAOs in DropWizard Tasks…
When mapping a Backbone Model directly to a REST API it is common for the resource you’re accessing to have a nested or associated resources. Backbone Models are a wrapper for a single resource, but do not attempt to implement a nested resource relationship. Backbone Collections also provide a nice mechanism to
fetch multiple resources at a time but also do not work well for a nested resource structure.
In our application we have a
Question model that has many
Answers. When using a collection to fetch our questions we also want, in the same call, to fetch the answers. This is what we’ve tried so far.
Read more on Nested Backbone Models…