Web Services vs API for Rookies
Hi Guys, I am so sorry for writing back after a long gap! I was occupied with so many things and I got sailed away from writing. I am back now...
I have got deluge of emails and requests,so I am writing again. I have observed that many of the HR professionals and people with zero knowledge on technical area are getting into Workday and a lot of freshers are showing interest to get into Workday jobs.
Most of them are in two minds and come with queries whether they have to write programs or mandatory to have technical experience on programming side ?
I suggest that to have knowledge is always good as you can understand the flow and the functionality easily.
You will tend to hear about web services in WORKDAY STUDIO, so I am writing the difference between web services and API for better understanding.
As you know that functional area doesn't require much knowledge on the technical aspects but when it comes to the integration and Workday Studio, I feel its better to have an idea on the API and Web services ( SOAP, REST)
I have already covered XML area in my blog.
I am writing this for peers who doesn't have any technical background. I hope this workday blog helps them.
Web Service vs API :
WEB SERVICE:
A Web service is designed to have an interface that is depicted in a machine-processable format usually specified in Web Service Description Language (WSDL). Typically, “HTTP” is the most commonly used protocol for communication. Web service also uses SOAP, REST, and XML-RPC as a means of communication.
It's a service available over the web. In a simple way to understand, here goes an example.
Lets take the restaurant scenario: A french customer visits an Indian restaurant and wants to order some traditional Indian food. The Hotel staff should be in a position to understand the french language to take the order and serve the customer their signature Indian dish.
At this point, the waiter who understands the language will be taking the order from the customer and translates the same to the kitchen department to cook.
In this scenario, the 'waiter' acts as a WEB SERVICE and customer and kitchen as TWO DIFFERENT LANGUAGE applications.
A Web service is merely an API wrapped in HTTP. An API doesn’t always need to be web based. An API consists of a complete set of rules and specifications for a software program to follow in order to facilitate interaction. A Web service might not contain a complete set of specifications and sometimes might not be able to perform all the tasks that may be possible from a complete API.
The APIs can be exposed in a number of ways which include: COM objects, DLL and .H files in C/C++ programming language, JAR files or RMI in Java, XML over HTTP, JSON over HTTP, etc. The method used by Web service to expose the API is strictly through a network.
Medium: HTTP/Internet
Format:XML/JSON
There are two types of web services -SOAP and REST
SOAP(Simple Object Access Protocol)- A web service that compiles to the SOAP web services specifications is a SOAP web service
Medium: HTTP ( POST)
Format: XML
W3C(world wide web consortium) defines the standards.
There are two SOAP web services specifications
1) Basic 2) Extended
* SOAP
* WSDL
* UDDI
All the information that happens between service consumer(CLIENT) and service provider(SERVER) is over a common format XML. XML message has a defined structure : SOAP MESSAGE consists of
* Envelope
* Header
* Body
Here is the SOAP XML structure:-
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encoding Style="http://www.w3.org/2003/05/soap-encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>
Envelope: It is the root element of a SOAP message. This is basic unit of the XML document which contains other units like Header and body.
Header: A element provide the information about the message itself. Header might include complex types, routing information etc.
Body: It contains actual data of the request that is meant to be sent to the server.
REST: REpresentational State Transfer----- It is more flexible and less rigid than SOAP
Medium:HTTP (POST, GET,PUT,DELETE,...)
Format: XML/JSON/TEXT
REST is often misunderstood in web service. A web service that communicates/exchange information between 2 applications using REST architecture is called as Restful web service . It is an architectural style . It doesn't have any protocol or strict specifications unlike SOAP and there is no central body controlling.
REST defines a set of principals to be followed while designing a service for communication/data exchange between 2 applications. When these principles are applied while designing web services ( client-server interactions) we get RESTful web service.
The principals of REST Architecture that should follow to become a restful web service
* Uniform Interface
* stateless
* cacheable etc...
Resource: Everything is a resource
URI: any resource/data is accessed by a URI
HTTP: make explicit use of HTTP methods
1) Resource: everything is a resource ...
Example- We are creating Human Resource tracking system ( HRTS). We can create this system on any platform and on any language and on any database at the back end.
To develop HRTS, we should have some modules like employees which will have attributes like 'employee name' and 'employee ID' and then Department module like 'Department name' and 'Department ID' and other modules.
The concept of resource says that we can define any information on any module as resource.
We can define resource as 'employee' 'department'... every module we can name as resource.
2) URI: we can access resource/data through URI ( uniform resource identifier)
If the HRTS software is developed and hosted somewhere and we can access it by using the domain name/ employees to get the employees data
http://hrts.com/employees ( we get all employees data).
If we want employee 26 details then we can access http://hrts.com/employees/26
3) HTTP: let us see how we make use of HTTP methods:
HTTP - GET, POST, PUT, DELETE are few methods. We can CREATE using POST
READ using GET, UPDATE using PUT and DELETE using DELETE----- CRUD ( SHORT FORM)
using HTTP methods along with URI, we can access/modify any resource or resource information.
REQUEST RESPONSE
GET- http://hrts.com/employees list of employees
GET- http://hrts.com/employees/26 lists details of employee with ID 26
DELETE- http://hrts.com/employees/26 deletes the details of employee with ID 26
POST- http://hrts.com/employees ID of new employee
+
Data of new employee
PUT- http://hrts.com/employees/26 modify data of employee 26
+
data to be changed
http:// GET hrts.com/employees/26
Difference between SOAP and REST web service to get the details of the employee having ID 26
SOAP
========================================================================
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encoding Style="http://www.w3.org/2003/05/soap-encoding">
<soap:Body pb="http://hrts.com/employees">
<pb:GetEmployee>
<pb:Empid>26</pb:Empid>
</pb:GetEmployee>
</soap:Body>
</soap:Envelope>
=============================================================================
REST
http://hrts.com/employees/26
In Rest we will not be writing the complete coding rather we go with simple link
============================================================================
COMPONENTS OF WEB SERVICES: 1) WSDL 2) UDDI
WSDL- Web service description language
Service provider publishes an interface for his web services that describes all attributes of the web services. This is XML based interface called WSDL.
CLIENT (service consumer) - SERVER(service provider)
There are two ways a service consumer can get hold of this WSDL document
1) If the service consumer and the service provider already know each other. The service provider can hand over the WSDL to the client and they can use the service.
2) When the service provider and the service consumer doesn't know each other... how can service consumer can get hold of WSDL document?
Ans: A web service provider publishes his web service (through WSDL) on an online directory from where consumers can query and search the web services. This online registry/directory is called UDDI ( Universal Description, Discovery and Integration)- It is an XML based standard for publishing and to find web services. It is like UDDI is a directory where the service provider will put WSDL documents where consumer can query and get hold of their choice WSDL document.
************************************************************************************************************
API ( Application Programming Interface) and Web service serve as a means of communication.
The only difference is that a Web service facilitates interaction between two machines over a network.
An API acts as an interface between two different applications so that they can communicate with each other.
An API is a method by which the third-party vendors can write programs that interface easily with other programs.
API may use any means of communication to initiate interaction between applications. For example, the system calls are invoked using interrupts by the Linux kernel API.
An API exactly defines the methods for one software program to interact with the other. When this action involves sending data over a network, Web services come into the picture. An API generally involves calling functions from within a software program.
In case of Web applications, the API used is web based. Desktop applications such as spreadsheets and word documents use VBA and COM-based APIs which don’t involve Web service. A server application such as Joomla may use a PHP-based API present within the server which doesn’t require Web service.
An API is nothing but the flexibility between two applications to talk to each other irrespective of the different program.
Ex: Google map API, YouTube API
Summary:
1. All Web services are APIs but all APIs are not Web services.
2. Web services might not perform all the operations that an API would perform.
3. A Web service uses only three styles of use: SOAP, REST and XML-RPC for
communication whereas API may use any style for communication.
4. A Web service always needs a network for its operation whereas an API doesn’t need
a network for its operation.
5. An API facilitates interfacing directly with an application whereas a Web service is a
If you have any queries, do not hesitate to write to me.
Hi Guys, I am so sorry for writing back after a long gap! I was occupied with so many things and I got sailed away from writing. I am back now...
I have got deluge of emails and requests,so I am writing again. I have observed that many of the HR professionals and people with zero knowledge on technical area are getting into Workday and a lot of freshers are showing interest to get into Workday jobs.
Most of them are in two minds and come with queries whether they have to write programs or mandatory to have technical experience on programming side ?
I suggest that to have knowledge is always good as you can understand the flow and the functionality easily.
You will tend to hear about web services in WORKDAY STUDIO, so I am writing the difference between web services and API for better understanding.
As you know that functional area doesn't require much knowledge on the technical aspects but when it comes to the integration and Workday Studio, I feel its better to have an idea on the API and Web services ( SOAP, REST)
I have already covered XML area in my blog.
I am writing this for peers who doesn't have any technical background. I hope this workday blog helps them.
Web Service vs API :
WEB SERVICE:
A Web service is designed to have an interface that is depicted in a machine-processable format usually specified in Web Service Description Language (WSDL). Typically, “HTTP” is the most commonly used protocol for communication. Web service also uses SOAP, REST, and XML-RPC as a means of communication.
It's a service available over the web. In a simple way to understand, here goes an example.
Lets take the restaurant scenario: A french customer visits an Indian restaurant and wants to order some traditional Indian food. The Hotel staff should be in a position to understand the french language to take the order and serve the customer their signature Indian dish.
At this point, the waiter who understands the language will be taking the order from the customer and translates the same to the kitchen department to cook.
In this scenario, the 'waiter' acts as a WEB SERVICE and customer and kitchen as TWO DIFFERENT LANGUAGE applications.
A Web service is merely an API wrapped in HTTP. An API doesn’t always need to be web based. An API consists of a complete set of rules and specifications for a software program to follow in order to facilitate interaction. A Web service might not contain a complete set of specifications and sometimes might not be able to perform all the tasks that may be possible from a complete API.
The APIs can be exposed in a number of ways which include: COM objects, DLL and .H files in C/C++ programming language, JAR files or RMI in Java, XML over HTTP, JSON over HTTP, etc. The method used by Web service to expose the API is strictly through a network.
Medium: HTTP/Internet
Format:XML/JSON
There are two types of web services -SOAP and REST
SOAP(Simple Object Access Protocol)- A web service that compiles to the SOAP web services specifications is a SOAP web service
Medium: HTTP ( POST)
Format: XML
W3C(world wide web consortium) defines the standards.
There are two SOAP web services specifications
1) Basic 2) Extended
* SOAP
* WSDL
* UDDI
All the information that happens between service consumer(CLIENT) and service provider(SERVER) is over a common format XML. XML message has a defined structure : SOAP MESSAGE consists of
* Envelope
* Header
* Body
Here is the SOAP XML structure:-
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encoding Style="http://www.w3.org/2003/05/soap-encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>
Envelope: It is the root element of a SOAP message. This is basic unit of the XML document which contains other units like Header and body.
Header: A element provide the information about the message itself. Header might include complex types, routing information etc.
Body: It contains actual data of the request that is meant to be sent to the server.
REST: REpresentational State Transfer----- It is more flexible and less rigid than SOAP
Medium:HTTP (POST, GET,PUT,DELETE,...)
Format: XML/JSON/TEXT
REST is often misunderstood in web service. A web service that communicates/exchange information between 2 applications using REST architecture is called as Restful web service . It is an architectural style . It doesn't have any protocol or strict specifications unlike SOAP and there is no central body controlling.
REST defines a set of principals to be followed while designing a service for communication/data exchange between 2 applications. When these principles are applied while designing web services ( client-server interactions) we get RESTful web service.
The principals of REST Architecture that should follow to become a restful web service
* Uniform Interface
* stateless
* cacheable etc...
Resource: Everything is a resource
URI: any resource/data is accessed by a URI
HTTP: make explicit use of HTTP methods
1) Resource: everything is a resource ...
Example- We are creating Human Resource tracking system ( HRTS). We can create this system on any platform and on any language and on any database at the back end.
To develop HRTS, we should have some modules like employees which will have attributes like 'employee name' and 'employee ID' and then Department module like 'Department name' and 'Department ID' and other modules.
The concept of resource says that we can define any information on any module as resource.
We can define resource as 'employee' 'department'... every module we can name as resource.
2) URI: we can access resource/data through URI ( uniform resource identifier)
If the HRTS software is developed and hosted somewhere and we can access it by using the domain name/ employees to get the employees data
http://hrts.com/employees ( we get all employees data).
If we want employee 26 details then we can access http://hrts.com/employees/26
3) HTTP: let us see how we make use of HTTP methods:
HTTP - GET, POST, PUT, DELETE are few methods. We can CREATE using POST
READ using GET, UPDATE using PUT and DELETE using DELETE----- CRUD ( SHORT FORM)
using HTTP methods along with URI, we can access/modify any resource or resource information.
REQUEST RESPONSE
GET- http://hrts.com/employees list of employees
GET- http://hrts.com/employees/26 lists details of employee with ID 26
DELETE- http://hrts.com/employees/26 deletes the details of employee with ID 26
POST- http://hrts.com/employees ID of new employee
+
Data of new employee
PUT- http://hrts.com/employees/26 modify data of employee 26
+
data to be changed
http:// GET hrts.com/employees/26
Difference between SOAP and REST web service to get the details of the employee having ID 26
SOAP
========================================================================
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encoding Style="http://www.w3.org/2003/05/soap-encoding">
<soap:Body pb="http://hrts.com/employees">
<pb:GetEmployee>
<pb:Empid>26</pb:Empid>
</pb:GetEmployee>
</soap:Body>
</soap:Envelope>
=============================================================================
REST
http://hrts.com/employees/26
In Rest we will not be writing the complete coding rather we go with simple link
============================================================================
COMPONENTS OF WEB SERVICES: 1) WSDL 2) UDDI
WSDL- Web service description language
Service provider publishes an interface for his web services that describes all attributes of the web services. This is XML based interface called WSDL.
CLIENT (service consumer) - SERVER(service provider)
There are two ways a service consumer can get hold of this WSDL document
1) If the service consumer and the service provider already know each other. The service provider can hand over the WSDL to the client and they can use the service.
2) When the service provider and the service consumer doesn't know each other... how can service consumer can get hold of WSDL document?
Ans: A web service provider publishes his web service (through WSDL) on an online directory from where consumers can query and search the web services. This online registry/directory is called UDDI ( Universal Description, Discovery and Integration)- It is an XML based standard for publishing and to find web services. It is like UDDI is a directory where the service provider will put WSDL documents where consumer can query and get hold of their choice WSDL document.
************************************************************************************************************
API ( Application Programming Interface) and Web service serve as a means of communication.
The only difference is that a Web service facilitates interaction between two machines over a network.
An API acts as an interface between two different applications so that they can communicate with each other.
An API is a method by which the third-party vendors can write programs that interface easily with other programs.
API may use any means of communication to initiate interaction between applications. For example, the system calls are invoked using interrupts by the Linux kernel API.
An API exactly defines the methods for one software program to interact with the other. When this action involves sending data over a network, Web services come into the picture. An API generally involves calling functions from within a software program.
In case of Web applications, the API used is web based. Desktop applications such as spreadsheets and word documents use VBA and COM-based APIs which don’t involve Web service. A server application such as Joomla may use a PHP-based API present within the server which doesn’t require Web service.
An API is nothing but the flexibility between two applications to talk to each other irrespective of the different program.
Ex: Google map API, YouTube API
Summary:
1. All Web services are APIs but all APIs are not Web services.
2. Web services might not perform all the operations that an API would perform.
3. A Web service uses only three styles of use: SOAP, REST and XML-RPC for
communication whereas API may use any style for communication.
4. A Web service always needs a network for its operation whereas an API doesn’t need
a network for its operation.
5. An API facilitates interfacing directly with an application whereas a Web service is a
If you have any queries, do not hesitate to write to me.
