0% found this document useful (0 votes)
23 views8 pages

SOA and REST API

Service-Oriented Architecture (SOA) is a design pattern for building distributed systems that deliver services through a protocol, characterized by loosely coupled, self-contained services. RESTful APIs, a simpler alternative to SOAP, utilize HTTP methods for communication and are favored for their lightweight and flexible nature. Key HTTP methods in REST include GET, POST, PUT, PATCH, and DELETE, each serving specific functions in managing resources.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
23 views8 pages

SOA and REST API

Service-Oriented Architecture (SOA) is a design pattern for building distributed systems that deliver services through a protocol, characterized by loosely coupled, self-contained services. RESTful APIs, a simpler alternative to SOAP, utilize HTTP methods for communication and are favored for their lightweight and flexible nature. Key HTTP methods in REST include GET, POST, PUT, PATCH, and DELETE, each serving specific functions in managing resources.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Service Oriented Architecture (SOA)

A Service-Oriented Architecture or SOA is a design pattern which is designed to build


distributed systems that deliver services to other applications through the protocol. It is
only a concept and not limited to any programming language or platform.

What is Service?

A service is a well-defined, self-contained function that represents a unit of functionality.


A service can exchange information from another service. It is not dependent on the state
of another service. It uses a loosely coupled, message-based communication model to
communicate with applications and other services.

Service Connections

The figure given below illustrates the service-oriented architecture. Service consumer
sends a service request to the service provider, and the service provider sends the service
response to the service consumer. The service connection is understandable to both the
service consumer and service provider.

Service-Oriented Terminologies
o Services - The services are the logical entities defined by one or more published
interfaces.
o Service provider - It is a software entity that implements a service specification.
o Service consumer - It can be called as a requestor or client that calls a service
provider. A service consumer can be another service or an end-user application.
o Service locator - It is a service provider that acts as a registry. It is responsible for
examining service provider interfaces and service locations.
o Service broker - It is a service provider that pass service requests to one or more
additional service providers.

Characteristics of SOA

The services have the following characteristics:

o They are loosely coupled.


o They support interoperability.
o They are location-transparent
o They are self-contained.

Components of service-oriented architecture


The service-oriented architecture stack can be categorized into two parts - functional
aspects and quality of service aspects.

Functional aspects

The functional aspect contains:

o Transport - It transports the service requests from the service consumer to the
service provider and service responses from the service provider to the service
consumer.
o Service Communication Protocol - It allows the service provider and the service
consumer to communicate with each other.
o Service Description - It describes the service and data required to invoke it.
o Service - It is an actual service.
o Business Process - It represents the group of services called in a particular sequence
associated with the rules to meet the business requirements.
o Service Registry - It contains the description of data which is used by service
providers to publish their services.
Quality of Service aspects

The quality-of-service aspects contains:

o Policy - It represents the set of protocols according to which a service provider


makes and provide the services to consumers.
o Security - It represents the set of protocols required for identification and
authorization.
o Transaction - It provides the surety of consistent result. This means, if we use the
group of services to complete a business function, either all must complete or none
of the complete.
o Management - It defines the set of attributes used to manage the services.

Advantages of SOA

SOA has the following advantages:

o Easy to integrate - In a service-oriented architecture, the integration is a service


specification that provides implementation transparency.
o Manage Complexity - Due to service specification, the complexities get isolated,
and integration becomes more manageable.
o Platform Independence - The services are platform-independent as they can
communicate with other applications through a common language.
o Loose coupling - It facilitates to implement services without impacting other
applications or services.
o Parallel Development - As SOA follows layer-based architecture, it provides parallel
development.
o Available - The SOA services are easily available to any requester.
o Reliable - As services are small in size, it is easier to test and debug them.

RESTful APIs: -
REpresentational State Transfer (REST) is an architectural style that defines a set of
constraints to be used for creating web services. REST API is a way of accessing web
services in a simple and flexible way without having any processing.

REST technology is generally preferred to the more robust Simple Object Access
Protocol (SOAP) technology because REST uses less bandwidth, simple and flexible
making it more suitable for internet usage. It is used to fetch or give some information
from a web service. All communication done via REST API uses only HTTP request.

Working: A request is sent from client to server in the form of a web URL as HTTP GET or
POST or PUT or DELETE request. After that, a response comes back from the server in the
form of a resource which can be anything like HTML, XML, Image, or JSON. But now JSON
is the most popular format being used in Web Services.

In HTTP there are five methods that are commonly used in a REST-based Architecture
i.e., POST, GET, PUT, PATCH, and DELETE. These correspond to create, read, update, and
delete (or CRUD) operations, respectively. There are other methods which are less
frequently used like OPTIONS and HEAD.
• GET: The HTTP GET method is used to read (or retrieve) a representation of a
resource. In the safe path, GET returns a representation in XML or JSON and an
HTTP response code of 200 (OK). In an error case, it most often returns a 404
(NOT FOUND) or 400 (BAD REQUEST).
• POST: The POST verb is most often utilized to create new resources. In
particular, it’s used to create subordinate resources. That is, subordinate to
some other (e.g. parent) resource. On successful creation, return HTTP status
201, returning a Location header with a link to the newly-created resource with
the 201 HTTP status.
• PUT: It is used for updating the capabilities. However, PUT can also be used
to create a resource in the case where the resource ID is chosen by the client
instead of by the server. In other words, if the PUT is to a URI that contains the
value of a non-existent resource ID. On successful update, return 200 (or 204 if
not returning any content in the body) from a PUT. If using PUT for create,
return HTTP status 201 on successful creation. PUT is not safe operation but it’s
idempotent.
• PATCH: It is used to modify capabilities. The PATCH request only needs to
contain the changes to the resource, not the complete resource. This resembles
PUT, but the body contains a set of instructions describing how a resource
currently residing on the server should be modified to produce a new version.
This means that the PATCH body should not just be a modified part of the
resource, but in patch language like JSON Patch or XML Patch. PATCH is neither
safe nor idempotent.
• DELETE: It is used to delete a resource identified by a URI. On successful
deletion, return HTTP status 200 (OK) along with a response body.

Request and Response


Now we will see how request and response work for different HTTP methods.
Let’s assume we have an API for all student’s data.

• GET: Request for all Students.

Request

GET:/api/students

• POST: Request for Posting/Creating/Inserting Data


Request

POST:/api/students
{“name”:”Raj”}

• PUT or PATCH: Request for Updating Data at id=1

Request

PUT or PATCH:/api/students/1
{“name”:”Raj”}

• DELETE: Request for Deleting Data of id=1

Request

DELETE:/api/students/1

RESTful web services are very popular because they are light weight, highly scalable and
maintainable and are very commonly used to create APIs for web-based applications.

1. What is REST?

Ans: REST (Representational State Transfer) is a design pattern for creating web
services. It establishes a set of constraints and principles for creating web APIs that are
flexible, scalable, and simple to maintain.

2. What is the difference between REST and RESTful?

Ans: REST is a set of architectural guidelines for building APIs. RESTful APIs are APIs
that adhere to REST guidelines.

3. What is the difference between RESTful and Non-Restful APIs?

Ans: RESTful APIs follow REST guidelines. On the contrary, Non-Restful APIs use other
methods/protocols like SOAP (Simple Object Access Protocol) for communication.
The most common HTTP methods used in RESTful APIs are GET, POST, PUT, PATCH, and
DELETE:

• GET: Retrieves data from a server. GET is considered a safe operation that does not
change the state of any resource on the server.
• POST: Used to create resources in a collection. When POST is applied to a parent
resource, it builds a new resource and adds it to the correct hierarchy.
• PUT: Replaces an existing resource with an updated version.
• PATCH: Updates a resource partially, rather than entirely.
• DELETE: Deletes a resource identified by a URL. DELETE is idempotent, which
means that the outcome is the same whether a request is sent multiple times or
once.

You might also like