Before moving on to the CQRS part, I would like to talk a bit about the advantages and disadvantages of REST. I don’t think it is possible to answer the question before we establish a common understanding of when and why to use REST.
REST
As with most other technology options, REST is also not a silver bullet. It has advantages and disadvantages.
I like to use the Richardson maturity model with an additional level of 0 Martin Fowler as a thinking tool.
Level 0
Martin Fowler also calls level 0 a POX swamp, but I think that what really sets this level apart is just using RPC over HTTP. It does not have to be XML; it could be JSON.
The primary advantage at this level is interoperability. Most systems can communicate via HTTP, and most programming platforms can process XML or JSON.
Disadvantage it is that systems are difficult to develop independently of customers (see level 3).
One of the distinguishing features of this style is that all communication passes through one endpoint.
Level 1
At level 1, you begin to view the various parts of your API as separate resources. Each resource is identified by a URL.
Advantage is that you can now use off-the-shelf software, such as firewalls and proxies, to control access to various parts of the system. You can also use HTTP redirects for point clients for different endpoints, although there are some pitfalls in this regard.
I can't think of any flaws except level 0.
Level 2
At this level, you not only have resources, but also use HTTP verbs such as GET , POST , DELETE , etc.
Advantage is that now you can begin to take advantage of the benefits of the HTTP infrastructure. For example, you can instruct clients to cache responses to GET requests, while other requests are usually not cached. Again, you can use standard HTTP firewalls and proxies to implement caching. You can get web-scale caching for free.
The reason that level 2 is based on level 1 is because you need each resource to be separate, because you want to be able to cache resources independently of each other. You cannot do this if you cannot distinguish different resources from each other or you cannot distinguish records from records.
Disadvantage lies in the fact that to implement this may require more programming work. In addition, all previous deficiencies are still applicable. Clients are closely associated with your published API. If you change the structure of the URLs, the clients will break. If you change the data format, the clients will break.
However, many so-called REST APIs are developed and published at this level, so in practice it seems that many organizations consider this a good compromise between advantages and disadvantages.
Level 3
This is the level of REST design that I consider true REST. This is not like previous levels; this is a completely different way to develop an API. In my opinion, there is a difficult gap between levels 0-2 and level 3.
One distinguishing feature of level 3 is that you should consider content alignment in the design of your API . However, if you have this, the reasons for choosing this API design style will become clearer.
For me, the dominant advantage of the Level 3 API is that you can develop them independently of clients. If you are careful, you can change the structure, even the navigation chart, of your API without breaking existing clients. If you need to make changes to the changes, you can use content negotiation so that customers can opt out of the change, while former customers will continue to work.
Basically, when I am asked to write an API in which I have no control over clients, my default choice is level 3.
Designing a Level 3 REST API requires you to design in a way that is unusual and alien to many, so there is a drawback . Another drawback is that client developers often find this API design style unfamiliar, so they often try to refine the URL structure,> If they do, you will have to spend some effort to stop them from doing this, as this will not opportunities for you to develop the API.
In other words, Layer 3 APIs require significant development efforts, especially on the server side, but clients also become more complex.
I will, however, repeat the advantage: you can develop a level 3 REST API regardless of clients. If you do not control customers, backward compatibility is required. Level 3 allows you to develop the API while maintaining compatibility. I don’t know how you can achieve this with any of the other styles.
Cqrs
Now that we have identified some of the advantages and disadvantages of REST, we can begin to discuss whether it applies to CQRS.
The most fundamental agreement between Greg Jan and Udi Dahan regarding CQRS is that it is not a top-level architecture .
In short, the reason for this is that the messages (commands and events) and queries that make up the CQRS system are interpretatively sensitive. To do something, the client must know which command to issue, and the server must know how to interpret it. Thus, the team is part of the system.
A system can be distributed between clients and servers, but messages and data structures are interconnected. If you change how your server interprets this message, this change will affect your clients. You cannot create clients and servers in the CQRS architecture yourself and independently, therefore this is not a top-level architecture.
Thus, given that this is not a top-level architecture, transport architecture becomes irrelevant. In a sense, the only thing you need to send messages is the only "service bus" endpoint, which can easily be a level 0 endpoint if you only need compatibility. After all, the only thing you do is queue a message.
The last answer, as always: depends.
Is delivery speed the most important criterion? And can you control all the clients and servers at the same time? Then perhaps level 0 is all you need. Maybe level 2 is fine.
On the other hand, if you have clients out of control (mobile applications, hardware (IoT), business partners using your public API, etc.), you should consider how to deal with backward compatibility and forward, a 3rd level is needed (IMO). In this case, I would suggest keeping CQRS in implementation details.