It's beneficial to streamline your service to embody the essence of $resource.

app.factory('friendService', [ '$resource', function($resource) {
    return $resource('/api/friends/:id', null, {
        'update' : {
            method : 'PUT'
        }
    });
} ]);

This approach automatically generates the following endpoints (which is one of the key advantages of $resource):

{ 'get':    {method:'GET'},
  'save':   {method:'POST'},
  'query':  {method:'GET', isArray:true},
  'remove': {method:'DELETE'},
  'delete': {method:'DELETE'}
};

Here are some examples of how to use it:

friendService.query(success, error); // GET /friends
friendService.get({ id : "exampleId" }, success, error); // GET /friends/exampleId
friendService.save({/* no params */}, friendObjectWithId, success, error); // POST /friends/idTakenFromObject
friendService.delete({ id : "exampleId" }, {}, success, error); // DELETE /friends/exampleId
friendService.update({/* no params */}, friendObjectWithId, success, error); // PUT /friends/idTakenFromObject

According to this line from the documentation, you can omit using $promise to define the callbacks:

non-GET "class" actions: Resource.action([parameters], postData, [success], [error])

So, you can simply execute something like this:

friendService.update({}, friendObject, successHandler, errorHandler)

In brief:

Your confusion seems to stem from misconceptions about the $resource in comparison to $http.

$resource acts as a wrapper around $http to facilitate Object Oriented CRUD interactions with a RESTful api. (The official documentation provides detailed explanations and examples)

Given the nature of your URL, it appears that a REST api may not be in use, making it more appropriate to utilize the $http service rather than $resource.

Here is a functional demo for reference.

---

Resource Usage and REST API Integration

In the context of Angular, a resource corresponds to a REST resource, necessitating alignment with REST principles for effective implementation. To illustrate, consider a hypothetical "Friend" scenario... (I will adjust your URLs to align more closely with REST API standards)

API Conceptualization

Envision the following REST+CRUD compliant setup (for a Friend resource)

Resource            URI             Supported Methods
Friend Collection   api/friend      GET, POST
Friend              api/friend/:id  GET, PUT

The primary tenet here is that each Resource is uniquely identified by a URI (a fundamental aspect of URI: -> Uniform Resource Identifier) with the HTTP Method (Verb) specifying the operation conducted on the Resource.

While REST encompasses broader concepts, I recommend exploring this SO POST or this insightful article or Roy Fielding's dissertation (the REST progenitor) for comprehensive understanding.

---

URL Formatting

URL structuring can trigger heated debates, with interesting perspectives outlined in this SO Post and an article by Roy Fielding addressing the topic. In essence, REST does not mandate clean URLs; the focus lies on being hypertext-driven. This dictates that given a starting point (URL), the API should be self-explanatory, allowing clients to "discover" resources autonomously, with resource types specified by media-types. This approach ensures that if a URL changes, the API remains functional without disruptions.

Hence, the following structures are acceptable:

Home                 /
Friend Collection    /foo
Friend Resource 1    /bar
Friend Resource 2    /baz

As well as:

Home                index.php
Friend Collection   index.php?q=api/friend
Friend Resource 1   index.php?q=api/friend/1
Friend Resource 2   index.php?q=api/friend/2

Or with mod_reqrite for "clean URLs":

Home                /
Friend Collection   /api/friend
Friend Resource 1   /api/friend/1
Friend Resource 2   /api/friend/1

Alternate variations:

Home                /index.php
Friend Collection   /friend.php
Friend Resource 1   /friend_1.php
Friend Resource 2   /friend_2.php

While servers are not mandated to follow a particular pattern, adhering to a structure, especially for SEO purposes or human comprehension, is recommended. The last example's reliance on individual scripts for each resource can complicate development (though not violating REST principles, it may defy basic programming rules like DRY...)

Angular-resource does have preferences regarding URL structure, although not obligatory...

For your specific inquiry, mod_rewrite is required to align with the aforementioned example. However, REST compliance can be achieved without mod_rewrite.

---

Implementing angular-resource Module

With a defined API scheme adhering to REST+CRUD principles, the angular-resource module can be efficiently leveraged.

We can create a client-side representation (interface) for "Friend".

//Custom actions
var actions = {
    update: {
        method: 'PUT'
    }
}

var friendUrl = "/api/friend/:id"; // typically obtained by reviewing the API, often the parent collection
var Friend = $resource(friendUrl, {id: '@id'}, actions);

To retrieve a friend, a GET request (with the specified id) is initiated;

Friend.get({id: 1}).$promise.then(
    function (response) {
        //console.log(response);
    }
);

DELETE and PUT requests (such as the custom action update) follow a similar principle. Additionally, $resource facilitates collection retrieval through the query method. Utilize this to fetch the friends collection.

Note the usage of a hardcoded URL for simplicity

In order to make a request, you must first establish your endpoint. Remember to execute a method on it, such as request.post({id: 1}).$promise; or

request.update({term: 'sample'}).$promise;