 <p>Let's define a term: <code>operation = command or query</code> from a domain perspective, for example <code>ChangeTaskDueDate(int taskId, DateTime date)</code> is an operation.</p> <p>By REST you can map operations to resource and method pairs. So calling an operation means applying a method on a resource. The resources are identified by URIs and are described by nouns, like task or date, etc... The methods are defined in the HTTP standard and are verbs, like get, post, put, etc... The URI structure does not really mean anything to a REST client, since the client is concerned with machine readable stuff, but for developers it makes easier to implement the router, the link generation, and you can use it to verify whether you bound URIs to resources and not to operations like RPC does.<br> So by our current example <code>ChangeTaskDueDate(int taskId, DateTime date)</code> the verb will be <code>change</code> and the nouns are <code>task, due-date</code>. So you can use the following solutions:</p> <ul> <li><code>PUT /api{/tasks,id}/due-date "2014-12-20 00:00:00"</code> or you can use </li> <li><code>PATCH /api{/tasks,id} {"dueDate": "2014-12-20 00:00:00"}</code>. </li> </ul> <p>the difference that patch is for partial updates and it is not necessary idempotent.</p> <p>Now this was a very easy example, because it is plain CRUD. By non CRUD operations you have to find the proper verb and probably define a new resource. This is why you can map resources to entities only by CRUD operations.</p> <blockquote> <p>Going back to the REST Service, the way I see it there are 3 options:</p> <ol> <li>Make RPC style urls e.g. <a href="http://example.com/api/tasks/" rel="nofollow">http://example.com/api/tasks/</a>{taskid}/changeduedate</li> <li>Allow for many commands to be sent to a single endpoint e.g.: <ul> <li>URL: <a href="http://example.com/api/tasks/" rel="nofollow">http://example.com/api/tasks/</a>{taskid}/commands</li> <li>This will accept a list of commands so I could send the following in the same request: <ul> <li>ChangeDueDate command</li> <li>ChangeDescription command</li> </ul></li> </ul></li> <li>Make a truly restful verb available and I create domain logic to extract changes from a dto and in turn translate into the relevant events required e.g.: <ul> <li>URL: <a href="http://example.com/api/tasks/" rel="nofollow">http://example.com/api/tasks/</a>{taskid}</li> <li>I would use the PUT verb to send a DTO representation of a task</li> <li>Once received I may give the DTO to the actual Task Domain Object through a method maybe called, UpdateStateFromDto</li> <li>This would then analyse the dto and compare the matching properties to its fields to find differences and could have the relevant event which needs to be fired when it finds a difference with a particular property is found.</li> </ul></li> </ol> </blockquote> <ol> <li><p>The URI structure does not mean anything. We can talk about semantics, but REST is very different from RPC. <a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm" rel="nofollow">It has some very specific constraints, which you have to read before doing anything.</a></p></li> <li><p>This has the same problem as your first answer. You have to map operations to HTTP methods and URIs. They cannot travel in the message body.</p></li> <li><p>This is a good beginning, but you don't want to apply REST operations on your entities directly. You need an interface to decouple the domain logic from the REST service. That interface can consist of commands and queries. So REST requests can be transformed into those commands and queries which can be handled by the domain logic.</p></li> </ol>