The REST architecture says that a resource is managed by the server and identified by a URL.
In that light /er/1/approval is not a reasonable URL or model to use, unless you have an approval object or entity that you manage and manipulate on the server side. Seems to me the entity is the expense report itself, which means, /er/1 is your URL path.
Now, as for verbs… you can send (POST) any message you like to that resource.
set data:
{ action: "modify", data: { purpose : "Club hopping" } }
approve:
{ action: "approve" }
add item:
{ action:"additem", data: { amount:72.13, category:113, note:"client dinner" }}
etc.
From Fielding’s Ch5, which defined REST,
The in-parameters (of a request) consist of request control data, a resource identifier indicating the target of the request, and an optional representation.
…and…
Control data defines the purpose of a message between components, such as the action being requested or the meaning of a response. It is also used to parameterize requests and override the default behavior of some connecting elements. For example, cache behavior can be modified by control data included in the request or response message.
Therefore if you’d like to perform multiple actions on a resource, then you should embed in the “control data” multiple messages or action requests. In my example, the posted data would be something like:
{ action: "modify", data: { purpose : "Club hopping" } }
{ action: "approve" }
But you’d probably want to generalize that so that it is:
{ actions: [ {action:"modify", data: {...} }, { action:"approve"} ] }
The messages or actions your server can handle on each particular type of entity are up to you to define.
ps: sometimes REST implementations use HTTP PUT to create a resource and POST to modify or act on an existing resource.
and: I liked the article, How to GET a cup of coffee.