Sorry for the broken commit but everything looks good now.

I think it is reasonable that a parseProvider is supplied - but I think that it should also be called from the resource constructor in case we need to create a resource instance from a json payload (e.g. from a websocket).
Related, I suggest we also have a encodeProvider that handles the other side of the coin - encoding the resource into json.
All that to say - is just adding another parameter on the end for responseDataParser the best, or perhaps an optional encoder object that supports 'encode'/ 'decode' - or 'toJson', 'fromJson'?

Makes sense about making it an object and adding the ability to encode the object differently. I wasn't thinking about the encode part because my though process was that if the format required the data to be in some.weird.struct, you would just create an object that looked like that but being able to keep you object normal and consistent and just encode them different, that would be better.

On the note about the constructor, I am not even sure how do do that. I though that you couldn't created an instance of a resource object as resources are just plain javascript objects. For example, to save a new resource, I thought the only way was to create a plain object and then do resourceName.save(object). Maybe if you could give me an example of the syntax on how to create a empty resource object, I would better know what you are talking about and how to go about this.

One other thing I was thinking about was also adding this to the actions. I can see cases where different actions return different data formats. Getting a list of objects might returns a format different from getting one object. Using Jira as my example again, searching for issues has the data returning in the response.issues field however getting just one object has the data returning as the response (like $resource excepts).

If I add this to the actions and the constructor, there needs to be some sort of order of precedence and I would tat this would be the logic order

action -> constructor -> factory -> default

If anyone else has any thoughts or comments of these plans, please let me know, otherwise I will probably start working on this stuff tonight or this weekend.

Thanks for taking the time to comment back. Re: encoding - our service layer is RoR so is expecting objects to be nested; e.g. {user: {name: 'filbert'}}. We also have some strange requirements around datetimes for encode/decode. Current we are wrapping the ngResource with a decorator to intercept the get/post - so being able to specify an encoder/decoder would simplify this a lot.

re: Constructor -
~ line 324 -
function Resource(value){
copy(value || {}, this);
}

This allows me to define a resource and then new one up:
var User = $resource('/user/:userId', {userId:'@id'});
var user = new User({name: 'foo'});

Notice the ctor is just doing a copy, same as the default response handler.

I need to think about the action-specific response handlers. Another option for those cases would be to make the 1 response handler dynamic enough to handle the different possibilities. Make keep the logic a little cleaner in ngResource. Just my initial thought.

The constructor thing makes sense and good to know that now.

I will experiment with having the constructor/factory encoder providers smart enough to handle different actions. My initial though is that this should be possible to pass the action name to the encode/decode providers and then have the provider decided what to do based on the action if they want. I will let you know what I come up with.

I rewrote the code to incorporate the comments that Mark made. Now you can pass an optional 4th parameter to the resource factory or an optional 2nd parameter to the resource constructor that take an object that can have an encode and/or decode function defined for encoding and decoding data to and from a REST API.

The encode function takes 2 parameters, first the data and then the action name and except the data structure that the REST API is excepting to be returned..

The decode function takes 2 parameters, first the response and then the action name and except the data to be returned from the REST API formatted response.

Both functions will default to current behavior if no custom functionality is given.

The reason the action name is passed is to be able to return or parse different data structures based on the action that is called.

I have also added in additional tests to test this new functionality.

+1 to add this feature. It will help to handle complex json object and also add/remove transient data that should not be persisted (added un decode and remove in encode).

Ryan - I'm getting ready to merge this into my branch and had a comment regarding the constructor: Rather than having constructorDataParsers, I think in most cases it would likely just use the same decode/encode as the factory definition. So, no need for a constructorDataParsers parameter - rather, the copy(value || {}, this) would use the decoder passed into the resource factory. So the constructor would look like:
function Resource(value)
copy(dataparsers.decode(value, 'constructor') || {}, this )
}

What do you think?

Having the option makes it more flexible - but seems like it may be overkill to have the constructorDataParsers.

This is not an approach which is consistent with the rest of the angular. A better way to do this is to allow resource to consume $http.config which already has transformRequest/Response functionality

See duplicate: #1045 (comment)

I am going to close this for now. If you would like to update it to allow full $http.config, please reopen for review.