REST Service and CQRS

Question

I am struggling with architecture on a new project. I am using the following patterns/technology.

• CQRS - anything going in goes through a command
• REST - using WebAPI
• MVC - asp.net mvc
• Angular - building a spa
• nhibernate

I belive this provides some great separation and should help keep a very complex domain from growing into a giant set of services that mix queries with other business logic.

• The REST services have become non restful. They are putting methods in rest that are "SearchByDate", "SearchByItem" etc.
• Service Methods that execute commands are called with a "web" model class, a new command is built in the service and executed, I feel like there is a lot of extra code.

I expected this to be much different but I wasn't around to keep things on track.

Finally my questions are this...

I would have liked to see PUT Person (CreatePersonCommand) but then I realized that isn't restful either is it? the put should be a person entity not a command.

Can I make CQRS and REST service work together or am I going about this all wrong?

How do I handle service methods that don't fit into a REST model. I am not performing CRUD on the object but rather executing some business logic. I.E. I don't want the UI to be responsible for how a shipment is "unshipped" I want the service layer to worry about that.

Answer 1

• REST works OK with a command model... the commands basically become nouns, or worker resources.

So instead of using

/blah/blah/SearchByName

You'd have a "search" (noun) resource

/blah/blah/search?Name=

I've always felt that's kind of a word game, but it does has the benefit of keeping your semantics resource oriented.

• In the case where the verb directly mirrors an HTTP verb, just omit it.

Instead of

/blah/blah/CreatePerson

it's just PUT to

/blah/blah/Person

...the call is the same, it's just that you're using the HTTP verb (PUT) instead of duplicating that in the resource name.

• Also, just stylistically, I don't think you need to add "Command" to all your URI's ;) It's kind of like having a "PersonResource", "CarResource", "CompanyResource", etc. Or like adding "Page" to all the URLs on the web: http://google.com/SearchPage, http://cnn.com/NewsPage, http://twitter.com/TweetsPage

CQRS is about splitting up your writers from your readers. It would be fair game under both CQRS and REST to add some resources that only accept POST -- using the "data processing" clause for POST provided in the HTTP spec. POST data for processing, then GET the resulting resources.

But as long as your resource names boil down to nouns rather than verbs, you can keep all the purists happy.

...

A Command name is just a combination of action + target. You're concatenating those to create your Command names "ActionTargetCommand".

In REST:

• the target goes in the base URI

• the action becomes the method or else implied from the query string

• and Command just goes away as redundant

"ACTION htpp://blah/Target?ActionParameter=".

You either need to make your action one of the HTTP methods, or else turn the resource into a processor noun.

One one level, it's just renaming to suit a resource-oriented paradigmn, but on a deeper level is a matter of splitting the commands into those covered by the HTTP methods, and others into processing nouns.

Answer 2

You probably need Event Sourcing then. Basically you store each event in something that resembles a serial queue and have some service process pick up the events on the queue and execute them. That way you can separate the code that submits the events from the code that executes their effects. You also get the benefit of being able to replay the events to reconstitute object state. I suggest you do some googling for Event Sourcing. It's a common companion to CQRS.