Client applications begin by getting the service description provided via the Web Services Description Language (WSDL). How the WSDL is retrieved varies depending upon the environment used to develop the client application. Once the WSDL defining the contract is retrieved and a proxy is created the application interacts with the API using standard SOAP requests.
The Web Services are described by individual service files from which the WSDL and XML Schema Definition ( XSD) is accessed using an URL similar to the following:
http://<<ServerIp:Port>>/iRes_NdcRes_WS/services/NdcResService17_2Port?wsdl
Note: Here the actual URL varies based on environment (Staging, Training and Production).The schema (Version 17.2 EDIST) corresponding to NDC can be downloaded from IATA website.
The Web Services API WSDL must be used to obtain the API contract for use by clients that use the API. Since the API is provided as a Web Service, the WSDL provides the needed interface definitions. This document does not intend to go into the details of Web Service technology, but focuses on how to effectively use iFly Res NDC Web Services.
The basic pattern of usage for the API is to instantiate an API ServicePort which logically groups a set of APIs for the functional area, for example, NdcResServicePort groups APIs which supports PNR creation flow. Once a ServicePort is instantiated it can be used to access to the APIs grouped within it. For programmers familiar with Object Oriented Model, the API ServicePort is similar to a class and all the APIs contained within it are methods of that class. Using an API method is similar to making a function call.
iFly Res NDC API accepts input as XML objects. Parameters required for building the request object are collected by the client application either by asking a user for it / requesting it from the system or from the response of predecessor services. Once the data is collected, the RQ (request) to a given API are populated and the API is then called. For instance, the shopAir operation in the NdcResServicePort needs an AirShoppingRQ object as an input parameter. If there are no exceptions, the API returns a response (RS) object which contains the results of the API operation. IBS would provide specific user/channel details which should be set as a mandatory data in the API request to iFlyRes system.
Any webservice consumers who intend to use iFly APIs only needs to establish a connection and have a method for generating SOAP requests to communicate with Web Services.