Is SOA the same as REST?

Question

I am learning about SOA in a college course. And from what I understand, SOA is tied to the concept of Web Services. There are also REST Apis that are also related to this concept.

Both terms give me some doubts.

Doubts

1. SOA is the same thing as REST?
2. When speaking of services compared to SOA, what kind of services are referring?
3. And what is this service?

Answer 1

If we consider that REST is a way to meet the requirements of web services and that this in turn is a form of SOUNDS (service-oriented Architecture), so although it’s not the same thing, but every REST is doing a SOA, there’s a hierarchical relationship between the terms.

SOA is an architecture. Web Service is a way to implement this architecture and REST is a mechanism specific to it. There is nothing opposite in them. If you do a REST correctly you will always be applying SOA.

As far as I know, there’s no formal definition of what a service is. It’s something that does a job, meets a demand, responds with something that’s relevant to a scenario. From what I understand it is something normally more isolated, probably remote and that can be consumed by several consumers, probably using different technologies, just knowing how to communicate with it.

At least Wikipedia says more or less that for SOA specifically, which obviously derivative services should follow:

• logically represents a business activity with some result.
• is self-contained
• is a black box for consumers
• may have other services behind it

There’s a Wikipedia article that says what a service is, but I found it kind of weak and specific. Maybe there’s nothing better. At least that’s the kind of service we’re talking about here.

Answer 2

If I understand correctly, the purpose of the author of this question is to relate the service to the real world, creating a metaphorical version of how to explain a service. For a technical definition of what is a service I suggest accessing this article in Portuguese: SOA - What is a service?, has examples and diagrams that can satisfy more academic opinions on the subject. If the previous link is offline I made a backup and added to my drive can be accessed here .

"SOA is the same thing as REST?"

Both SOA and REST are architectural decisions on how to organize your client/server software project. More than that, they are opposite decisions: choosing one means that you are choosing not to use the other. SOA (Service Oriented Architecture) focuses on the delivered service, on how data is handled, while REST is concerned about the data being processed.

It is clear that the service-oriented architecture (SOA) is service-oriented, and a resource-oriented architecture (REST) is resource-oriented. The differences between A and B are often best explained by the definition of the essence of A and B, so it boils down to the question, what is a "service" and what is a "resource"?

Although it seems very clear, it is not so easy to distinguish services and resources, they can often be confused or even interpreted ambiguously. Looking for a clearer example, I found in the international SO on a similar issue the example:

Flickr is a service that provides photos, but can also be seen as a feature for photos. But basically a feature is more static data (like a photo) and a service is more processing (for example, delivering a photo or resizing a photo so that they can show a thumbnail of a photo).

Very often the feature is confused with document or static data, is able to find on the internet talking that a resource is an XML or a JSON, but not only that, the resource is an object with a type, associated data, relationships with other resources and a set of methods that do operations on it. It is similar to an object instance in object-oriented programming languages, with the important difference that only a few standardized methods are defined for a resource - corresponding to the standards of the HTTP protocol: GET(list), POST(creates), PUT(updates) and DELETE(remove) - while an object instance can have several methods without a fixed pattern. So XML or JSON are just ways to represent this resource.

For example, a person’s data may represent the "Person" feature, with attributes name, age, with a related feature of "Address" with its specific attributes and so on.

Roughly speaking, this is the summary of what is a refusal in REST architecture, the system will be built around these known resources, since its methods are already known and standardized.

Knowing what REST (B) is, we can finally separate what SOA (A) is and focus on the question,

"When it comes to services compared to SOA, [...]?"

When we go to SOA, the architectural basis is the services, ie the functionalities that can process and/or deliver data given an internal logic, these services will dictate how the software project will be built, affecting all application modeling and future software maintenance. To talk about the service types first define

"What is this service?"

Seeking a more academic definition it is possible to obtain the following definition of software engineering books:

A service is a unit of solution logic to which service guidance has been applied significantly. It is the application of service orientation design principles that distinguish a unit of logic as a service compared to units of logic that may exist only as objects or components. (...) Each service receives its own distinct functional context and is composed of a set of resources related to that context. Therefore, a service can be considered a recipient of resources associated with a common purpose (or functional context).

(author’s translation), Source: http://serviceorientation.com/soaglossary/service

In accordance with the standard proposed by Opengroup (entity that aims to establish standards and policies, and share best practices. ), a service has four properties :

• It logically represents a commercial activity with a specific result.
• Is autonomous.
• It’s a black box for your consumers. (Your consumers don’t know the internal logic)
• May consist of other underlying services (sub-services).

Different services can be used together to provide the functionality of a large software application. So far, the definition could be a definition of modular programming in the 1970s. The service-oriented architecture (SOA) is less about modularizing an application and more about composing an application by integrating distributed, maintained separately, and deployed software components. It is enabled by technologies and standards that make it easier for the component to communicate and cooperate over a network, especially an IP network.

I better understand the difference when analyzing how software implements its "functionality":

An application created with a Service Guidance (SOA) architecture combines or composes its feature-based output functionality that is in the services it uses "behind the screens". For example. Basic processing consists of calling external services, providing parameters, and combining the results for the user. The Standard is very common 'Façade' of the English Facade Patern (diagrams in the English article are clearer) for building SOA applications.

"[...] what kind of services are referring to?"

Services can still be grouped into 2 categories:

• Business Services : "Business Services" or "Business Services" are services that perform specific business functions and are necessary for the successful completion of a business process. They can also be called Application Services, as they are used to develop composite services and business applications that automate business processes. For example, a retail company may have an "Inventory/Inventory Service", "Customer Management Service" and "Shipment Service" in its business services repository, each of them with its own distinct business rules and can also communicate between itself or be sub-service of another larger service.

• Infrastructure Services : Can be found in the academic literature as "Services Structures" or "Infrastructure Services", are part of a central management infrastructure component, such as an Enterprise Service Bus (ESB link in English). Infrastructure Services provide the technical functionality needed to implement business rules in SOA, but do not directly add business value. Examples of infrastructure services include Integration Services, Authentication Services, Event log services.

Although there are several approaches to categorize the different types of services in SOA, the main distinction to remember is that of Business Services and Infrastructure Services. Infrastructure services are agnostic and have greater possibilities for reuse, while business services translate directly into business rules. The possibilities of reusing Business Services vary according to the way they are designed.