Dereferencing objects with angularJS' $resource

Question

I'm new to AngularJS and I am currently building a webapp using a Django/Tastypie API. This webapp works with posts and an API call (GET) looks like :

{
    title: "Bootstrap: wider input field - Stack Overflow",
    link: "http://stackoverflow.com/questions/978...",

    author: "/v1/users/1/",

    resource_uri: "/v1/posts/18/",
}

To request these objects, I created an angular's service which embed resources declared like the following one :

Post: $resource(ConfigurationService.API_URL_RESOURCE + '/v1/posts/:id/')

Everything works like a charm but I would like to solve two problems :

1. How to properly replace the author field by its value ? In other word, how the request as automatically as possible every reference field ?
2. How to cache this value to avoid several calls on the same endpoint ?

Again, I'm new to angularJS and I might missed something in my comprehension of the $resource object.

Thanks, Maxime.

Answer 1

With regard to question one, I know of no trivial, out-of-the-box solution. I suppose you could use custom response transformers to launch subsidiary $resource requests, attaching promises from those requests as properties of the response object (in place of the URLs). Recent versions of the $resource factory allow you to specify such a transformer for $resource instances. You would delegate to the global default response transformer ($httpProvider.defaults.transformResponse) to get your actual JSON, then substitute properties and launch subsidiary requests from there. And remember, when delegating this way, to pass along the first TWO, not ONE, parameters your own response transformer receives when it is called, even though the documentation mentions only one (I learned this the hard way).

There's no way to know when every last promise has been fulfilled, but I presume you won't have any code that will depend on this knowledge (as it is common for your UI to just be bound to bits and pieces of the model object, itself a promise, returned by the original HTTP request).

As for question two, I'm not sure whether you're referring to your main object (in which case $scope should suffice as a means of retaining a reference) or these subsidiary objects that you propose to download as a means of assembling an aggregate on the client side. Presuming the latter, I guess you could do something like maintaining a hash relating URLs to objects in your $scope, say, and have the success functions on your subsidiary $resource requests update this dictionary. Then you could make the response transformer I described above check the hash first to see if it's already got the resource instance desired, getting the $resource from the back end only when such a local copy is absent.

This is all a bunch of work (and round trips) to assemble resources on the client side when it might be much easier just to assemble your aggregate in your application layer and serve it up pre-cooked. REST sets no expectations for data normalization.