SOA communication RESTful API and Message BUS, is it common to have both?

Question

I understand their own characteristics but a lot of articles focus on comparing the two methods but never talked about they serve different purposes within SOA.

Eg. Example of ticket system and identity management.

1. When creating a ticket I can assign to a person from a list, which the list gets from identity management, this is most likely calling RESTful API due to the synchronous nature of the request. Same thing during the ticket creation, it fetches the person data to create a local record so the new ticket can link to it.

2. When the user changes his first name, the identity management publishes the changes over the message bus, and the service desk system updates the 'cached' person data on its own database.

So, both of the communication methods are used for their advantage. Is this normal for SOA projects? Also, it seems a bit of duplication of work using 2 different communication methods, am I wrong?

Answer 1

It is very common for large systems to use both. Often, it's even much more complex, with multiple message queue systems being involved, REST being used side-by-side with SOAP, DCOM, CORBA, etc.

Is it a good idea to use both for a new system? It often is. In fact, both have their limitations, and so at a given step, you realize that you need to introduce an MQS if you have used only REST, or REST if you used only MQS.

This being said, don't put both MQS and REST from the beginning "just in case." Use YAGNI and common sense: if you absolutely need both, so be it. If not, stick with the things you need and keep your system as simple as possible.

• James Lin: Thanks, In this case RESTful covers more use case.