@burke, yes, I envision that we have a couple utility functions that are can (a) add common implementations of retire, unretire, query, etc, to each XyzService, and (b) take a response returned by $resource and return our own standardized object with paging functions, etc.
Also, before we rush into writing a bunch of code here, someone should investigate Restangular which claims to be better than ngResource in various ways (and I think @rcrichton recommended it, based on their findings in OpenHIE).
@wyclif, if we’re going down the ngResource path, to introduce a “nice” unretire function we would do something like this:
var ProviderService = {
// ...
unretire: function(objectOrUuid) {
// one-liner that delegates to Provider/ProviderResource, which is a $resource(...)
}
}
The point is that the Provider/ProviderResource is the raw underlying implementation, and ProviderService is our nicer utility that is easier to use. It is incorrect and misleading to call the underlying resource “EncounterTypeService” and to call our nicer convenience methods “EncounterType”, as you propose in your first comment on RA-900. (I’m not really sure if we are disagreeing about anything other than naming here; I’m presuming that the “unretire” function is on the second factory in the js file.)
Generally, my takeaway from the initial implementation is that it is a mistake to try to pretend that the underlying REST behavior isn’t there, and we shouldn’t try to hide it. It seems to me that you are trying to name things in a way that hides the underlying behavior, which is only going to confuse things in the long run.