A Web service is a service made available on the Web to be utilized by other Web applications. It facilitates platform independent communication between applications over the web. For example, an application written in C++ on a Windows platform can easily communicate with an application written on JAVA on a Linux platform through a Web service exposed by an API and exchange information.

An example of a Web service would be Make Trip Website/App. Let us take a scenario where a user tries to book a flight ticket from Delhi to Mumbai on a particular date and hits the search button. Within a few seconds the list of available flights from the respective airlines such as Go Air, Jet Airways, Spice Jet, and so on display. Flight statuses are ever changing and therefore, when the user is booking the flight, it is possible for the flight to get canceled due to bad weather, technical or personnel reasons. An important piece of information like flight cancellation must be notified to the user immediately and this is possible only if Make  Trip has access to real-time data of the airlines.

For obvious security and business reasons none of these airlines will directly expose their databases to be infiltrated by some unknown party. However, they can provide access to their data through Web services. All these airlines have exposed their Web services through an API to the third party applications such as Make Trip to utilize their data real-time. Make trip has configured these Web services to query the databases of all these airlines real-time and provides information to the user.

The above example has been illustrated as follows:

Benefits of Web Services Configuration in Canvas

Configuring Web services through Studio will now eliminate the need to write instruction class to perform the following actions:

• To connect to the Web service.
• To provide a request payload (data that needs to be retrieved from or pushed into the system).
• To parse the response to the payload request.

Web Services Authentication Support in Canvas

Canvas supports Representational State Transfer (REST) Web Services. A common format or industry-standard authorization mechanism is used by the applications to send out and receive information. Canvas supports the following industry-standard authorization mechanisms to configure the REST Web services:

1. No Authentication: Web services based on the 'No Auth' authorization mechanism are not secure as they do not require the third party applications to register with them and complete authorization in order to access information provided by them. For example, http://services.groupkt.com offers a Web service called State which is based on the No authentication authorization mechanism. Usually, if an application has several Web services that need to interact internally, No authentication mechanism is preferred.
   
   Go back to Authentication Type in the Creating a Web Service Connection section.
   
   
2. oAuth 2: Web services based on the oAuth 2 authorization mechanism allow third party applications to obtain limited access to user accounts on an HTTP service such as Facebook, GitHub, and so on. It works by delegating user authentication to the service that hosts the user account and authorizing third party applications to access the user account. Let us take a hypothetical example to understand oAuth 2 based Web services. Let us assume you want to compare the home loans offered by various banks on XYZBazar may want to analyze your banking statistics first and therefore, directs you to an authentication link (bank's Web service authentication page) asking for your bank credentials. When you provide your credentials, you authorize XYZBazar to access your details. The bank's Web service authorizes XYZBazar, generates authorization code and redirects you to XYZBazar.
   
   XYZBazar requests an access token from the Web service by passing the authorization code along with authentication details obtained while registering with the Web service. If the authorization is valid, the Web service sends the access token to the application. After getting authorized, XYZBazar may use the token to access your banking details via the Web service limited to the scope of access until the token expires or is revoked.
   
   The following illustration depicts the OAuth 2 authorization flow for applications followed by a detailed explanation:
   
   
   
   The above illustration is explained in detail as follows:
   
   

   (1) Application Registration - Register your application with the Web service by providing details of you application such as the application name, Website and redirect or callback URL. The redirect URL is the URL to which the users are redirected after they authorize or deny your application.
   
   After successful registration of the application, client credentials (Client ID and Client Secret) are generated. The client credentials are used by the Web service to authenticate the identity of your application to the service when the application requests to access a user's account.

   (2) User Authorizes Application - The user logs into the authentication page (bank's Web service authentication page) and is prompted to authorize or deny the application access to their account. 

   (3) Application Receives Authorization Code – When the user authorizes the application to access the data, the service redirects the user to the application redirect URL which was specified during the client registration along with an authorization code.

   (4) Application Requests Access Token - The application requests an access token from the Web service API by passing the authorization code along with authentication details, including the client secret to the API token endpoint.

   (5) Application Receives Access Token - If the authorization is valid, the API will send a response containing the access token to the application. After the application is authorized, it may use the token to access the user's account via the service API limited to the scope of access until the token expires or is revoked. If a refresh token was issued, it may be used to request new access tokens if the original token expires.
   
   Go back to Authentication Type in the Creating a Web Service Connection section.

   
   

3. API Key: Web services based on the API Key authorization mechanism are less secure and do not require end user (resource owner) authentication compared to oAuth 2 authorization mechanism based Web services. When you register your application with the Web service, an API key and sometimes a secret is generated which is sufficient to fetch data from the service. The additional steps involved in oAuth 2 authorization, such as generation of authorization code and access token after the resource owner authenticates the application are not required. For example, in the case of Make  Trip example, the Web services offered by the airlines could be based on API Key authorization.
   
   Go back to Authentication Type in the Creating a Web Service Connection section.

Web Services Connectivity

The proxy server has its own IP address, which is made public. To access the Web service, ensure that this IP address and the port number are specified in the application server's environment variable. This can be performed either before or after configuring the Web service. For more information, watch Web_Service_Integration_via_Internet_Proxy (MP4). Alternatively, the proxy server's IP address and the port number can be specified in the systempreferences.properties file. For more information, see Configuration Descriptor: System Preferences.

After you log into Sigma Studio, refer Create a Web Services Connection.