REST URI Templates for Query and Command operations

Question

We have an application that is split into two parts:

1. Admin - Where data is changed
2. Public - Where data is read

I'm looking at creating a REST API to provide this functionality. It's very easy to see how CRUD operations can be represented but I am not sure about specific operations (commands) on an individual resource. For example to "Publish" a Project we send a "PublishCommand". We don't PUT the full Project back to the server with its Published property set to true.

On a similar note, I am a little confused at how we should represent more advanced query operations on resources without being classed as a RPC type service.

Below I've listed the URI templates for my Project resource. Am I on the right track for creating a truly RESTful API?

ADMIN API
---------

// Project Resources
GET /projects -- get all projects
POST /projects -- create a new project

// Project Resource
GET /projects/10 -- get project with id 10
PUT /projects/10 -- update project with id 10
DELETE /projects/10 -- delete project with id 10

// Project Resource Operations
POST: /projects/10/publish -- publish project with id 10
POST: /projects/10/unpublish -- unpublish project with id 10
POST: /projects/10/setposition/2 -- move to position 2 in projects list

// Project Sub resources (identity is local to project)
POST: /projects/10/media -- adds media to project with id 10
PUT: /projects/10/media/5 -- updates media id 5 for project id 10
DELETE: /projects/10/media/5 -- deletes media id 5 from project id 10

PUBLIC API
----------

GET: /projects -- gets all projects (with default limit e.g. first 10)
GET: /projects?skip=10&take=10 -- gets projects 11 to 20
GET: /projects/tagged/rest OR /taggedprojects/rest -- gets projects tagged with "REST"
GET: /projects?orderbydesc=publishdate OR /latestprojects -- gets latest projects

GET: /projects/10 -- gets project with id 10

Answer 1

I don't think that REST is intended to only represent CRUD operations. Your interface looks fine to me, and I believe you're on the right track.

There's a talk online about DDD and REST: RESTful SOA or Domain-Driven Design - A Compromise? by Vaughn Vernon.

Update to include a comment I made below:

You can query yor read model using GET. To mutate your domain you can PUT or POST to resources that represent commands. This would provide the richness of a domain model beyond CRUD and still use the inherent semantics of HTTP.

Answer 2

If you look at publishing as a resource, then you can use CRUD (POST/GET/PUT/DELETE):

• POST to create a publish, passing project id
• DELETE to unpublish
• GET to retrieve

This does not mean that the process has to be associated with physical creation of records in database. It is just the resource-based approach which is important.