WO2017220505A1

WO2017220505A1 - A method, system and computer programs for enriching application program interface (api) input information in a telecommunication system

Info

Publication number: WO2017220505A1
Application number: PCT/EP2017/064963
Authority: WO
Inventors: Yang XIAOYUAN; David Guijarro Guillem
Original assignee: Telefonica Digital España, S.L.U
Priority date: 2016-06-24
Filing date: 2017-06-19
Publication date: 2017-12-28

Abstract

The method comprises receiving, by a backend system (300), from a web browser (100) installed on a user terminal device, a request for a web page; sending, by the backend system (300), the requested web page to the web browser (100) along with a link allowing the requested web page interacting with a third-party API backend (400); intercepting, by a network element (200), a request made by the w3eb browser (100) to the third-party API backend (400) for a programming language block of the third-party API backend (400); modifying, by the network element (200), the programming language block of the third-party API backend (400) and returning the modified programming language block to the web browser (100); and executing, by the web browser (100), the modified programming language block according to a logic implemented by the requested web page.

Description

A method, system and computer programs for enriching Application Program Interface (API) input information in a telecommunication system

Technical Field

The present invention relates to a method, a system, and computer programs for enriching API input information for open APIs in a telecommunication system.

Background of the Invention

Web ecosystem is evolving to becoming one of the most interconnected systems that have ever been created in the human history. Each web service is no longer a simple isolated web page where one company manages all resources. Nowadays, each web page retrieves information from multiples services where independent organisms manage the behavior of each service. The interoperability of different services is the key for the success of the current web ecosystem and it is achieved by defining pre- established interfaces, called Application Program Interface (API). APIs can take multiple forms depending on the application. It could be as simple as REST API based on top of existing HTTP protocol. It could be in form of library where a set of public functions is available for new applications. It could be in form of a JavaScript that instantiate a public object with multiples functionalities inside the web page. Independent of the form of API, the goal is to isolate the underlay complexity and abstract entire service in a user-friendly layer where new services/applications can interact with it. With a well-defined API, the service looks like a black box that provides an expected output given a certain input data.

As services are getting more complex, available APIs are rare case a single function. Normally, a simple functionality requires multiple ways to interact with it. The reason behind is that applications use the same functionality in different ways. For instance, Google Doubleclick advertisement platform provides an open API based on JavaScript with more than 50 functions. There are functions for defining advertisement slots in the web pages; there are functions to define the targeting audience; there are functions to display the final advertisement. Depending on the needs of each web page, the developers can just call a subset of these functionalities. Independent of the complexity of the API, most of services assume that all information required is provided by the application. It is responsible of application to prepare correctly the input information to get the expected result. In some cases, however, not all information is available when an API is called by an application. For instance, location information is critical for some APIs. User devices may not have such capacity to track the location information when API is called. In such cases, the API can't be used to provide the service to the user.

In order to maximize the usefulness of the service, APIs normally define multiple functions with default input values, so developers can use the service even though not all required information is available. For instance, in case of Google Doubleclick, two versions are available to define advertisement slots. First version requires the developer to specify a list of slot sizes whereas the second version doesn't need any input size and Doubleclick service is responsible to decide the final size for the shown advertisement. Although default values for unknown input parameters are interesting to extend the usability of APIs, the established default final behaviors for the service could be not optimal for usefulness of the service, specially, if the unknown information could be complemented by other elements inside the information chain. In case of geo-location, device location could be well computed by network elements, rather than relaying a default value or IP based geo-location estimations.

One of most popular API model is the one that is being used in web pages. When a web page wants to use a third party API, the web page includes a link to download one or several codes, or scripts resources, such as JavaScript resources, from third party API backend. The code or script, is then executed in the user web browser to make a set of public functions available for the web page. The web page will then call different functions of this API, triggering more interacting with API backend or perform changes in the own web page. All this process is shown in Fig. 1 .

Some related proposals are the one disclosed in WO-A2-2012173823 relating to information enrichment for data base query responses. In network level, EP-A1- 2543176 proposes header enrichment for uplinks to improve QoS. Although all two proposals and present invention may use a network element in the architecture, present invention proposal is for programming language (such as JavaScript) enrichment for API services for web pages.

In US 201 10197200, authors propose to decode geolocation information in content to trigger native application. Although the proposal is related with enrichment, it is for user experience improvement and only related with geolocation information. In term of solution and domain is completely different to present invention proposal.

Solutions such as Blue Coat®, OpteNet® and Awazza® could potential enrich API calls or perform content filtering inside the network. However, such solutions are based on deep content analysis for injection and filtering, whereas present invention proposal is to modify transparently the programming language that interacts with the open API services.

Description of the Invention

Embodiments of the present invention provide a method to enrich API input information for open APIs in a telecommunication system. The proposed method as commonly in the field comprises receiving, by a backend system, from a web browser installed on a user terminal device, a request for a web page, and sending, by the backend system, the requested web page to the web browser along with a link allowing the requested web page interacting with a third-party API backend.

Unlike the known proposals, the method further comprises intercepting, by a network element, a request made by the web browser to the third-party API backend for a programming language block of the third-party API backend; modifying, by the network element, the programming language block of the third-party API backend and returning the modified programming language block to the web browser; and executing, by the web browser, the modified programming language block according to a logic implemented by the requested web page.

According to the proposed invention, the programming language block of the third-party API backend is a code, or script. Preferably the programming language block is JavaScript.

The modifying step comprises defining different default parameters for one or more API functions defined in the programming language block, or controlling invalid parameters on the programming language block. The programming language block has different information blocks (or sub-blocks), each one containing different variables or functions. Besides, according to the proposed invention, the modifying step comprises including two additional information blocks to said different information blocks, one of the additional information blocks (or Top-Block) being included on the top of the different information blocks and the other additional information block (or Footer-Block) being included at the bottom/end of the different information blocks.

According to an embodiment, the Top-Block is intended for modifying external API variables, whereas the Footer-Block is intended for modifying public API functions or for modifying an initial state of global API variables.

According to an embodiment, at the same time the web browser executes the modified programming language block (i.e. runtime); the network element further downloads information about the web browser from the third-party API backend, and further modifies the modified programming language block executed by the web browser. The modification of the programming language block is performed in a transparent manner to the requested web page, so the logic implemented by the requested web page is not modified.

According to an embodiment, the modified programming language block is cached in the web browser. Other aspects that are disclosed herein also include a system, and software programs to perform the method embodiment steps and operations summarized above and disclosed in detail below. More particularly, a computer program product is one embodiment that has a computer-readable medium including computer program instructions encoded thereon that when executed on at least one processor in a computer element causes the processor to perform the operations indicated herein as embodiments of the invention.

Even, other aspects of the present invention may include a network element adapted and configured to intercept different functions in open API and enrich the input information thereof by introducing other parameters that are available in the network or introduced by an end-user. The proposed network element is set in the middle of the information chain and intercepts the API's programming language block implementing the API interactions. Once intercepted, the network element overwrites different functions that API provides for developers to call. In some sense, new versions of the API functions are created to capture new capabilities for the functions that are not initially thought for.

Therefore, the developers don't need to worry about compatibility of the API functions, because all interface signatures are keep untouched. Neither service needs to worry about the miss utilization of the API, because the initial function could be called at end.

Brief Description of the Drawings The previous and other advantages and features will be more fully understood from the following detailed description of embodiments, with reference to the attached figures, which must be considered in an illustrative and non-limiting manner, in which:

Fig. 1 is a flow chart illustrating current API utilization in a web page.

Fig. 2 is a flow chart illustrating how an API's programming language block is intercepted inside a telecommunication network.

Fig. 3 illustrates the modification scheme for API JavaScript enrichment according to a preferred embodiment of the present invention.

Fig. 4 is a flow char illustrating an API function Over-write.

Detailed Description of Preferred Embodiments With reference to Fig. 2 this figure shows a method for enriching API input information in a telecommunication system, such as the system of Fig. 1. Present invention, in addition to the elements disclosed in Fig. 1 , namely a web browser 100 installed on a user terminal device (not shown) such as a PC or a Smartphone, among others, a web page backend system 300 and a third-party backend 400, introduces a network element 200, set in the middle of the information chain, that coordinates all network interaction between the web browser 100 and the rest of elements. The exact form of this network element 200 is irrelevant for the invention. It could be a transparent proxy, an explicit proxy or even a Deep packet inspection (DPI), among others. Once the web browser 100 has requested a web page (html web page) (5) and has received the requested web page from the backend system 300 along with a link allowing the requested web page interacting with the third-party API backend 400, the network element 200 intercepts a request (6, 7) made by the web browser 100 to the third-party API backend 400 for the API's programming language block (which is a code, or script), and performs enrichment (8) on the API's programming language block by modifying it. Then, the modified programming language block is returned to the web browser 100 (9). That is, the network element 200 captures the programming language block from the third-party API backend 400 and over-writes API functions to perform information enrichment. For instance, the network element 200 can define default parameters for one or more API functions defined in the programming language block or perform control on invalid input parameters therein.

The modified programming language block will be executed (10) by the web browser 100 according to the web page logic. API enrichment could require network interactions to retrieve information in run time. According to an embodiment, the network element 200 downloads information about the web browser 100 from the third-party API backend 400 in run time. In such cases, further enrichments could be triggered in the network element in run time (1 1 ).

Any modification that network element 200 introduces for enrichment should not demand any modification in the requested web page. Specifically, the requested web page should be able to perform same calls to interact with the service. In this sense, all modifications should be transparent. Present invention defines a scheme to all modifications to achieve transparency in all API enrichments.

Fig. 3 shows the modifications that network element 200 introduces in the programming language block for API enrichment.

To be noted that present invention is used for all open APIs, regardless of the programing language thereof. However, according to a preferred embodiment, present invention is used to enrich API input information for open APIs based on JavaScript.

According to the preferred embodiment, all existing API JavaScript may contain 4 information blocks (or sub-blocks): 1. Global Variables 31 1 that are used to keep some states. The global variables could be public, accessible by web pages, or private (designed for internal uses).

2. Private Functions 312 that are used to support overall API calls.

3. Public Functions 313 that are public and called by web pages to retrieve services. 4. Initial Calls 314 that are optionally performs to instantiate some initial states.

The network element 200 injects two additional blocks, one in the beginning and one at end of the JavaScript blocks 31 1 , 312, 313, 314. The goal of the first block (or Top- Block) 315 is to perform external variable enrichments. For instance, some JavaScript may change the behavior reading several external variables, during the Initial Calls 314. The Top-Block will change the values of external variables to perform enrichments before the initial calls are triggered.

The second block (or Footer-Block) 316 is injected at end of the JavaScript blocks 31 1 , 312, 313, 314 and after the Initial Calls 314. The goals of Footer-Block are to perform public API Function over-writes and modifications in the initial state of global API variables.

With reference now to Fig. 4 therein it is illustrated an API function over-write for public API function. In JavaScript, all functions are defined with a unique reference name. It can have a list of input parameters and it could optionally return a value.

The public API function over-write consists in, first, finding a unique non-existing reference name 402 to store the initial function 403. It, then, creates the enriched new function for the API with same input and output parameters, just like the initial API function 404. The enriched new function overwrites the initial function by using the same reference name and it could, of course, call the initial function if it required.

Next it is shown an example of API that retrieves physical shops that sells a list of products. The public function is physical_shops (line 9) where input parameter is a list of products and optionally a price range.

The JavaScript performs an initial call by calling initial_call() in line 30. The initial_call will call a private function (private_determine_location(), line 4) to compute the user location that will be saved in a global variable (user ocation, line 1). Furthermore, an external variable (gender) could be used by the web page to set a target gender for physical shops. The external variable is read in initial_call function in line 21 . Once downloaded the JavaScript, the web page only need to call physical_shop() to retrieve the list of shops that provides the target products. Optionally, the web page could give a target price range.

The following shows the resulted JavaScript after enrichment by the network element 200. In the Top-Block (line 1 -3) 315, the enrichment changes the external variable to be male. This could be useful, when gender information is not available in the web page, but well known by the network element 200. In the Footer-Block (line 34-42) 316, the enrichment performs two parts. First, the network element 200 sets the user location to "New York". This could enable same API to be executable in user devices where location information is not available, but known by network element 200. Second, the network element 200 overwrites the public function physical_shops(), in line 36-41. The over-written function sets unconditionally the price range to be between 100 and 500 dollars. The price range could be given by users or inferred by network element 200 to enrich the API calls. It also calls the initial function in line 40.

Present invention enables a set of new API interaction models, where not all required information necessary for being used by the API comes from the web page (API client). A third element, network element 200, can transparently provide further information related with users or network to supply more required information.

Present invention enables the possibility to control information exchange between web page and third-party API backend 400. Sensitive information, such as user location or user personal information could be filtered out before calling API functions. The filtering process is performed when the API's programming language block is run in the web browser 100. This has huge advantages compared with Blue Coat solution, where filtering process is done inside the network, because communication with third-party API backend 400 could be encrypted, disabling any kind of possible content analysis and filtering. Present invention performs enrichment in the API's programming language block level, respecting the open API function signature. The advantage of such proposal is that web pages don't need to change the behavior to enjoy the enrichments.

The proposed scheme for public API function over-write is safe and it could adapt changes that could happen in successive API's programming language block updates. As far as public open API interface is respected, the API enrichment is applicable. This is normally the case, because interface change demands changes in all web pages that use the API, which is not reasonable for well-established web API services.

The enriched version of the API's programming language block could be cached in web browser 100. This has huge advantage for Smartphones where the device downloads content from multiple access mediums, such as multiple WiFis and mobile networks. Since enriched programming language block is cached, the user could enjoy the enrichment even the device switches to other networks where enrichment network system is not available. Present invention can be implemented by means of software elements, hardware elements, firmware elements, or any suitable combination of them. If implemented in software, the functions may be stored on or encoded as one or more instructions or code on a computer-readable medium.

Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD- ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Any processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal. As used herein, computer program products comprising computer-readable media including all forms of computer-readable medium except, to the extent that such media is deemed to be non-statutory, transitory propagating signals.

The scope of the present invention is defined in the following set of claims.

Claims

1. A method for enriching Application Program Interface (API) input information in a telecommunication system, the method comprising:

- receiving, by a backend system (300), from a web browser (100) installed on a user terminal device, a request for a web page; and

- sending, by the backend system (300), the requested web page to the web browser (100) along with a link allowing the requested web page interacting with a third-party API backend (400),

characterized in that the method further comprises:

- intercepting, by a network element (200), a request made by the web browser

(100) to the third-party API backend (400) for a programming language block of the third-party API backend (400);

- modifying, by the network element (200), the programming language block of the third-party API backend (400) and returning the modified programming language block to the web browser (100); and

- executing, by the web browser (100), the modified programming language block according to a logic implemented by the requested web page.

2. The method of claim 1 , wherein the modifying step comprises defining different default parameters for one or more API functions defined in the programming language block, or controlling invalid parameters on the programming language block.

3. The method of claim 1 , wherein the programming language block comprises different information blocks, each one containing different variables or functions, and wherein said modifying step comprises including two additional information blocks to said different information blocks, one of the additional information blocks being included on the top of the different information blocks and the other additional information block being included at the bottom of the different information blocks.

4. The method of claim 3, wherein the additional information block included at the top of the different information blocks of the programming language block is intended for modifying external API variables.

5. The method of claim 3 or 4, wherein the additional information block included at the bottom of the different information blocks of the programming language block is intended for modifying public API functions or for modifying an initial state of global API variables.

6. The method of previous claims, wherein at the same time the web browser (100) executes the modified programming language block, the network element (200) further downloads information about the web browser (100) from the third-party API backend (400), and further modifies the modified programming language block executed by the web browser (100).

7. The method of any of previous claims, wherein the modification of the programming language block is performed in a transparent manner to the requested web page, so the logic implemented by the requested web page is not modified.

8. The method of claim 1 , wherein the modified programming language block is cached in the web browser (100).

9. The method of any of previous claims, wherein the programming language block is a code, or script.

10. The method of any of previous claims, wherein the programming language block is JavaScript.

1 1. A system for enriching Application Program Interface (API) input information in a telecommunications network, comprising:

- a web browser (100) installed on a user terminal device;

- a backend system (300); and

- a third-party API backend (400),

wherein the backend system (300) is adapted and configured to receive from the web browser (100) a request for a web page and to send the requested web page back to the web browser (100) along with a link allowing the requested web page interacting with said third-party API backend (400),

characterized in that it further comprises:

- a network element (200) being adapted and configured to interact with the web browser (100), the backend system (300) and the third-party backend, by means of:

- intercepting a request made by the web browser (100) to the third-party API backend (400) for a programming language block of the third-party API backend (400); - modifying the programming language block of the third-party API backend (400) and returning the modified programming language block to the web browser (100); and

- executing the modified programming language block according to a logic implemented by the requested web page.

12. The system of claim 1 1 , wherein the programming language block is a code, or script.

13. The system of claim 1 1 or 12, wherein the programming language block is JavaScript.

14. A non-transitory computer readable medium having stored thereon computer executable code for enriching Application Program Interface (API) input information in a telecommunications network, the executable code causing one or more processors to perform the method steps of any of the claims 1 to 10.