I already have a stable Service Oriented Architecture for my application which exposes services as API calls. (the verbs)

Now, I need to build a Resource Oriented Architecture to expose a RESTful API to interact with the application objects. (the nouns)

What are the best practices to reuse the existing services:
- without any persistence inside my new code.
- without putting unnecessary logic into the REST layer i.e. it should ideally just leverage the services provided by SOA API. I want this layer to be as thin as possible.
- without modifying the existing SOA API
- allow easy extension of the REST API i.e. it should be easy to add more resources without changing the (yet to be written) core code. (I want to make resource names and their associated actions configurable so more contributors can easily add resources without a need to understand my module)

Any advices/suggestions how to achieve this?

Edit: Adding more info
My Stack:

• My existing stacks is in Java. But since I plan to just use the services, I don't think that should affect the design of new REST code.
• I am planning to implement the new REST code in PHP.

How well the services map to resources?
Some services are mapped well i.e. there are services for creating, updating application objects.
But for other application objects, there are no direct services available.

More importantly, there are actions beyond just create, update etc. that apply to application objects. And I would like to provide some way for these actions to be exposed through REST. Since these are verbs, how do I deal with them?

Where exactly I need help?
I would appreciate any help towards high level design to accomplish the task along-with making the framework extendible. For instance, tomorrow there are some new services added to my SOA layer, I want to make sure it is easy for a fresh developer to write a REST call by simply registering a new resource (in a config file/db) and write code for connecting it with SOA calls. Just like plugin.