The question is whether it makes sense for the RPC methods to appear in the REST of the resources indicated in the message
In a nutshell; no, it makes no sense to map methods to resources the way you describe :)
To successfully "make REST", we must think a little differently and abandon all the thoughts of RPC and CRUD operations; they are really quite limited once you turn on RESTful!
Key abstraction of information in REST is a resource. Any information that can be called can be a resource: a document or image, temporary services (for example, "today is the weather in Los Angeles"), the collection of other resources, not a virtual object (for example, a person), and so on. In other words, any concept that may be the target of an author hypertext link must meet the definition of a resource. A resource is a conceptual mapping to a set of objects, not an object that corresponds to a mapping at any particular point in time. http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
A method or action / verb then is not a resource, so it does not belong in a URI - unless, of course, you create an application that allows people to create their own methods, which would be quite unusual!
Taking your specific example for contact and event relationships , it’s important to understand that your AssignContactToEvent is an action that occurs under the Web-API layer and cannot be modeled RESTfully; Hope this becomes clear in the following examples :)
First we need good resources to simulate a list of all contacts and a list of all events:
/contacts /events
These resources model an individual contact or event identified by an identification marker:
/contacts/{contact_id} /events/{event_id}
Users of your application want to know who is participating in a particular Event, so we need a resource that models the list of participants in the event:
/events/{event_id}/participants
When we want to add a contact to the event, we could POST get the minimum Contact representation (containing only Contact-ID) in the list of participant participants:
POST /events/{event_id}/participants/ HTTP/1.1 Content-Type: application/json {'id': {contact_id}}
Removing a contact from an event:
DELETE /events/{event_id}/participants/{contact_id} HTTP/1.1
Your user applications also want to see at a glance the events in which the Contact participates, therefore, to simulate this, another resource is required:
/contacts/{contact_id}/events
Similarly, you can now get a list of events for a contact and assign events using POST:
POST /contacts/{contact_id}/events/ HTTP/1.1 Content-Type: application/json {'id': {event_id}}
An important point to take on board is that whenever you need to model something new, you create a resource. Information about how you store the properties and relationships of data objects is distracted by the web API. In fact, the storage technology may change in the future, say, from a relational relation to the object store, or you will change your programming language or framework, but in all cases your URI (and web API) will remain the same. REST and HTTP are designed to survive far beyond the technologies that work under the hood.
As a final example of creating new resources, consider a resource that models a list of contacts that have the role of organizer:
/events/{event_id}/organisers
or one that models the list of events that Contact organizes:
/contacts/{contact_id}/events-organised
If you have an authentication system, you can see the events you attend:
/my-account/events
Hope this helps clarify the purpose of the web API and follow RESTful principles.