Should I use ROA or SOA for a distributed application and how could I implement REST If using ROA

Question

For my final year project I'm looking to build a distributed version of a popular benchmarking client (this has already been done using various methods involving some form of existing frameworks), I have been advised by my dissertation supervisor to consider implementing a RESTful service. Essentially what will be happening is that a program will be started from one client (provided the details of the benchmark) , which shall initiate a master program / server who will then decide how many network nodes to run and on how many clients of which to run it on. These will all perform various actions on the database, have their own individual results returned to them & subsequently the original program / server that initiated them where the results will be aggregated.

I saw a few documents online stating that SOA's are useful where there will be many stateless processing units (the network nodes, in my head in the diagram) and said that an SOA includes a main storage (database cluster in my diagram) as well as an application that combines and composes them together (the clients on the networks nodes results will be being aggregated).

On the contrary I have read up on ROA's and RESTful service and it looks like it could fit this design pattern also.

So my question is, which of these design patterns shall I implement:

SOA or ROA?

And if ROA, I'm struggling to wrap my head around the CRUD operations in a situation other than a web service.

So for example, my network nodes will each be running a client interacting with the database individually (not via REST).

How would I include a GET / PUT / DELETE / POST to the client?

Because all I'm imagining in my head is GET in the context of GET databaseX/1 and retrieving an individual record or something similar.

Thank you in advance.

Answer 1

The first things first. There are two completely different types of "API"s people call RESTful.

First, the original meaning as described by Roy Fielding essentially describes how you create a web application. A RESTful API is basically a web-application for machines, but works exactly as a web-application for humans. That is, it starts with a landing page, you can click links, search, fill out forms, things like that.

At no point (except maybe the first URI) does a human construct a URI with parameters from memory. Nor should a machine. At no point does a human actually know where a link goes before it is clicked. Nor should a machine.

Here is an article of mine about 5 common things that are not RESTful.

Here is how a true RESTful client would approximately look like.

Note: Not many implement this kind of REST. Some think it is not needed, some don't even know it is supposed to work like this. Because of this there are also very few good tools to implement.

The second type is the most common one. This is basically SOA all over again, but with JSON and over HTTP instead of channel-agnostic XML we did previously for SOAP.

Here the client knows all resources before even talking to the server, knows what resources point to what other resources, knows what representation to expect when following a link, or often times there are no links at all.

This is the type of REST most people mean when they say REST. This is mostly CRUD-based, uses maybe Swagger/OpenAPI, or even GraphQL.

So I would say your options are:

1. RESTful the original sense. Web-application for machines.
2. RESTful in the more widespread sense. This is basically SOA, but more CRUD instead of commands and JSON over HTTP.
3. SOA, essentially XML or JSON channel-agnostic.

All 3 are viable for your case, as far as I can see. To decide between these, there are usually requirements. Like long-term maintainability, upgradeability, etc. When all of those are important, the choice should be 1. If not, then 2. I would choose 3 in a live project only if there is some weird requirement explicitly specifying it.

I would also ask your supervisor. If he/she doesn't care or even doesn't know what RESTful means, and you just want it done quick, you're better off with option 2. As a reference I needed multiple years to wrap my head around option 1 properly.