What are web services?
Web service is an application located on a server, which, in addition to its basic purpose, is designed to support interaction between two machines over the network and enable the exchange of information between them. Any service is considered to be a web service if:
- Available via the Internet or (internal network)
- Uses a standardized message system
- It is recognized by the search engine
- It is not tied to an operating system or programming language
Web service search
Web Services are published in a unique location where they are offered as services. UDDI (Universal Description, Discovery and Integration) is a centralized location that provides a mechanism for registering and finding Web services. UDDI uses SOAP for communication and allows clients to find a service as well as a server to publish it.
Services can be closed (private) but also publicly available. You can view the list of publicly available services on several websites:
- github.com/public-apis/public-apis
- any-api.com/
- rapidapi.com/collection/list-of-free-apis
- github.com/toddmotto/public-apis
Web service description
Web services have the ability to describe themselves, and WSDL (Web Service Description Language) is used to describe the service. WSDL is written in XML and contains information about where the web service is located and what communication protocol it uses.
Cooperation with GUI application
Web services in cooperation with a GUI application are something between a web and a desktop application. The web service on the server provides functionality and data, while the desktop application only provides a customizable graphical interface that it fills with the data received from the service. A web service in cooperation with a GUI application is more flexible than a web application because the user can adjust the appearance of the application on the client, while the user of the web application must use a web browser and has no influence on how the application will look on the screen.
Advantages compared to the web application:
- They are more economical in terms of network and server resource load because during communication they only send a response, while web applications send HTML with a form and a description of how the comment should be displayed in addition to the response. Web services are ideal for “small” devices that are not PCs, ie. mobile Pocet PC… because only the front-end application is installed on such a device, and the hard part is done on the server.
- They are easier to develop, test and maintain. With a web application, in addition to the necessary functionality, it is also necessary to test the design on all browsers and platforms, while with a web service, the author only cares about the function, while the client application cares about the display.
At the service, communication takes placebetween the client and the server by the client sending a request to the server which then the server receives the request and processes it, then forms a response based on it and then sends it back to the client. The client-server architecture style separates the problems of the two sides of the communication channel, which means that the client side is not at all interested in the way information is stored on the server because there is always a uniform way of accessing those resources. On the other hand, the server is independent of the client and doesn’t care how the user interface is implemented or what state a particular client is in, which greatly simplifies the server side. With this, their independence was achieved and the development of both sides was more easily separated, i.e. it is possible, for example, improve the server side or completely change its logic without the client noticing at all as long as the way of accessing the resources is the same.
What is an API?
In order to achieve communication between two systems, they need to have a “point” of contact, the so-called. interface. An interface is an intermediary (connection) in communication between two separate systems that work together and can be:
- Hardware interface (e.g. the steering wheel, throttle and gearbox are “vehicle access points” and represent an intermediary between the car and the person driving it)
- Program interface so called. “API” which represents “access points” for communication between two programs
Working with services implies that resources are accessed on a remote server (access is through the Internet), this kind of network communication brings with it the problem of accessing and transferring complex data structures as well as the organization of resources on the server itself. Over time, programmers have created communication between the two programs in various ways, ie. made different types of APIs, but at one point they standardized the way of communication, i.e. they created a set of rules that network applications should follow when communicating with each other (eg one such standardized api is “REST API”).
What we must pay attention to is that once the API is defined and put into “traffic”, in case changes need to be made after some time, it is not wise to change the “end points” that have been set so far, because it would be at least rude to force API consumers to change already created programs in order to adapt to the change. When a change is made, you should always strive to continue support for existing properties (end points), and for changes, add new properties instead of changing existing ones.
Types of web services
The main protocol for data transport between the web service and the client is HTTP, although it is possible to use other protocols. The data transfer format is XML or JSON.
a) Big Web Services (so-called SOAP-based services)
These services follow SOAP standards and data is transferred in XML format and described by WSDL. The use of the SOAP protocol enables communication between applications on different operating systems and different technologies, so that the applications exchange messages in an “agreed” format.
There are several different types of messages in SOAP, the most famous is the remote procedure call (so-called Remote Procedure Call – RPC). It is a type of message in which one node in the network (the client) sends a requestanother node (server), after which the server returns a response to the received request. This protocol is the successor of the XML-RPC protocol. It uses the same transport rules but has a different message structure.
Areas in which SOAP-based services “do well” are:
- with formal contracts when both parties need to agree on a format for exchanging information
- code operations using states
The disadvantage of SOAP-based services is the complexity and excessive “extensiveness” when using XML, although this disadvantage does not prevent Microsoft and IBM from using it very often. Another disadvantage is the consumption of resources to parse the XML.
- Envelope element (identifies the XML document as a SAOP message) is a mandatory part
- Capture (header) which is an optional part
- Body (body) is a mandatory part and carries information (parameters) of the request and returns results, i.e. the response of the Web series.
- Fault element which is optional and provides information about what to do if an error occurs while processing the message
b) RESTful web services
These services are more easily integrated with HTTP than SOAP services, they do not require XML messages or WSDL service descriptions. Today, RESTfull has stood out as the dominant network service, supplanting SOAP and WSDL because it is significantly simpler to use.
REST API Features
REST is an acronym for “Representational State Transfer” and refers to the way/principles of API creation. Data is most often transferred in JSON format, although XML and YAML formats are also available. The API is based on REST architecture and is very flexible and easy to understand.
With this type of API, resources (eg static pages, files, database data…)
The same URL is used for all operations, but the HTTP method that defines the type of operation is changed. REST uses “CRUD like” HTTP methods such as: GET, POST, PUT, DELETE, OPTIONS.
RESTful services have the following features and characteristics:
- Cacheable
- Uniform interface (Uniform interface URI)
- Explicit use of HTTP methods
- XML and/or JSON transfer
- Non-existence of state (“stateless”), which means that the server does not remember any data about the client, i.e. that with each request the client must send all the necessary information to understand and process that request, and not rely on the server to “recognize” it (that is, use information from previous requests of the same client). See the image below:
Application of RESTfull services
RESTfull services are used:
- at limited bandwidth and resources (feedback can be in any form)
- with operations that do not use state (if an operation needs to be continued then REST is not the right approach and SOAP is probably a better solution)
- for situations where caching is possible (if information can be cached due to non-state operations then this approach is great)
Advantages of RESTfull service
The features of the RESTfull service are:
- simplicity
Clients calling REST services do not need to format requests according to the SOAP specification and do not need to parse the SOAP response in order to extract a result from it. - flexibility of returned data format
The format in which the data is returned is not predefined and depends on the service itself. Clients can request data in the format that suits them best, unlike the SOAP format which, although standardized, must be parsed. So JavaScript can get data in JSON format that it can easily read, and RSS reader in RSS-XML format that it can display. - use of existing network infrastructure
- quick mastering of the technique
In the following image you have an example of an api that is not adapted to the REST architecture:
NOTE:
REST is not a protocol like SOAP, but a concept that is based on changing the state of the client and all actions are performed at the moment of changing that state, with the possibility of returning to one of the previous states.
c) Web services based on POX (Plain Old XML)
There is a growing trend among pragmatic developers to use Plain Old XML with a “REST like” URL and the best of the SOAP protocol. This service uses “raw” XML for data transfer, and GET and POST methods for communication. When it is said that it uses raw XML, it is not wrapped in any other message protocol envelope. This type of service is simpler and faster than SOAP service, and it retains the “strongly-typed API” which is the biggest advantage of SOAP service.