Patent Application
20110161991
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the United States Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
This technology generally relates to building web pages, and more particularly to a parallel API client controller and method for automatically handling flow control to build a combined web page using data retrieved from a plurality of API requests.
The World Wide Web has become a primary source of communication amongst millions of individuals in recent years. Web sites provide collections of web pages that are accessed by individuals for entertainment, education, information exchange, and even online shopping. As a result, more and more businesses have turned to the Internet to market and advertise to potential customers, to disseminate information about their brands to the public, and to accept orders for their products and services.
Traditionally, business web sites were created by computer programmers who “hard coded” the web sites using a combination of programming languages compatible with HyperText Markup Language (HTML). These programmers would create the site by writing lines of software code describing how the web site should look and the content that the web site should contain. The software code would then be uploaded to a server, where it could be assembled into a number of web pages and accessed by visitors to the web site. Depending on the breadth of the site, it could often take many hours to generate a web site in this fashion. Furthermore, it was very expensive for businesses to maintain web sites over time due to the specialized knowledge needed by the programmer to create the various web pages.
As technology progressed and businesses realized the high value of Internet advertising, web sites became more advanced, with more expansive content, multiple linked web pages, and high-end graphics and videos. Due to the high costs involved in hiring web developers to program and code these advanced web sites, software companies created web site development programs capable of automating the web creation process. This software can be used to build web sites either from scratch or from pre-existing templates. For example, a user can select, display, and arrange various web objects, such as text, graphics, media, and the like, through the page, in a “what-you-see-is-what-you-get” fashion. Then, the software development program automatically codes the web page into HTML, without the use of a web developer. HTML provides a way to add structure to the web page documents by providing structural semantics for text such as headings, paragraphs, and lists as well as for links, and other items.
However, users of traditional web site development software face many difficulties. For instance, the user must establish precise uniformity of the web site despite the visual inaccuracies of the “drag and drop” format, requiring intense time, skill, and effort. For example, the user must ensure the correct proximity of display objects, alignment, and consistency of format. With respect to business web sites, the user has to ensure uniformity across multiple, even hundreds or thousands, of linked web pages. Furthermore, this traditional web site development software often does not have the level of complexity required by many of today's businesses that want to integrate advanced functions, such as real-time media, into their web sites. Thus, the web pages and web site could become out-of-date and inconsistent, deteriorating the look and feel of the company web presence, and thus the visitor's impression of the company.
In both preparing hard coding and in preparing web development software, a web software developer is needed to generate the web site in accordance with the objectives of the business. Typically, this means that editors, designers, and product managers, who have the most intimate understanding of the business, are not directly involved with the generation of the web site, and must relay this business information to the web developer. It may take a number of drafts and iterations before the editor or designer is satisfied that the web site created by the developer properly reflects the business desires and objectives for the web site.
One example in the present disclosure is a parallel API (application program interface) client controller that provides a tool to build web sites when web page information is sourced from different APIs. In this context, an API is a defined set of Hypertext Transfer Protocal (HTTP) request messages, along with a definition of the structure of response messages, usually in an Extensible Markup Language (XML), JavaScript Object Notation (JSON) format, or similar structures. For a given web page being developed, a software web page developer can use the parallel API client controller, which allows the developer to configure various API requests that are needed to provide the different data necessary to assemble the web page. The parallel API client controller can be configured by the developer to alter the manner in which the model required by the web page is built.
In the examples below, systems and methods are provided for building a controller to build, integrate, and render pages of content. In a Model-View-Controller configuration, for example, the parallel API controller provides software developers and web developers with a controller to handle flow control and to build the Model required by the View (web page). The parallel API controller leaves the developer to develop the web page content. The parallel API controller can be configuration driven. The parallel API controller provides an easy-to-use and efficient manner to allow designers and editors direct control over the data available to the page, and allow for multiple party integrated-content pages. Further, the pages can have consistent layouts and formats, if desired, without the need for extensive programming.
In one example, a developer can use the API client controller and a model and leave the developer to focus upon developing the view or page template. The API client controller provides a way to create web pages that are based upon a collection of API requests. The data returned from the different API requests can then be used to create a model web page.
The examples in this application provide methods, systems, and media for configuring an API parallel controller to build a model required by a web page so that developers may integrate and dynamically build pages of content.
One example provides a method to build a controller framework for web sites when web page information is sourced from different APIs. In one example, a computer-implemented method uses an application program interface (API) client controller to build a model view. The method includes mapping an API path to an API request by a requestor device. The method further includes executing the API request to retrieve content by an executor device, retrieving content, and converting the retrieved content to a content data structure by a converter device. In this example, the method includes inserting the content data structure in a web page template and creating a model view based upon the inserted content data structure and the web page template.
In one example, the API path can be a uniform resource identifier (URI). Additionally, in one example, the API request can be an API call. The content can reside in an API database in one example. Further, converting the retrieved content to a content data structure can include converting the content data structure from an XML format to a Java Map object. The retrieved content can be stored in a memory device.
In one example, the method can also include determining a web page template to use in creating the model view based upon a characteristic of the content data structure. Further, the method can also stop execution of the API request to retrieve content after a predetermined amount of time.
In one example, the method can also include executing an additional API request to retrieve additional content, retrieving the additional content, converting the retrieved additional content to an additional content data structure, and inserting the additional content data structure in the web page template to create the model view. Further, executing the API request to retrieve content and executing the additional API request to retrieve additional content can be executed in parallel.
One example provides a system to build a controller for web sites when web page information is sourced from different APIs. In this example, the system can include a controller, a requestor, an executor, and a requestor executor. The system can also include a converter. The controller can be configured to handle requests for a given URI path pattern that matches the URI of the request. The requestor is a component that can be configured to map to a given API request that should occur. The executor is an interface for a number of components that is configured to execute a given action. Further, the requestor executor is a component that can be configured to make an API request to a given API for a configured requestor. The converter is a component that converts the data returned by the API calls to a data structure that can be easily consumed in the page templates and thereby provide a developer a convenient manner of building a web site when web page information is sourced from different APIs.
In one example, a computer readable medium has instructions stored on it for building and configuring an application program interface (API) client controller to build a model view. The computer readable medium includes instructions for mapping an API path to an API request by a requestor device. When executed by at least one processor, the instructions on the computer readable medium cause the processor to perform steps including executing the API request to retrieve content by an executor device, retrieving content, and converting the retrieved content to a content data structure by a converter device.
The instructions on the computer readable medium further cause the processor to perform steps including inserting the content data structure in a web page template and creating a model view based upon the inserted content data structure and the web page template. As above, in one example, the API path can be a uniform resource identifier (URI). Additionally, in one example, the API request can be an API call. The content can reside in an API database in one example. As indicated above, converting the retrieved content to a content data structure can include converting the content data structure from an XML format to a Java Map object. The retrieved content can be stored in a memory device.
The instructions on the computer readable medium further cause the processor to perform steps including determining a web page template to use in creating the model view based upon a characteristic of the content data structure. Further, the instructions can also stop execution of the API request to retrieve content after a predetermined amount of time.
In one example, the instructions on the computer readable medium further cause the processor to perform steps including executing an additional API request to retrieve additional content, retrieving the additional content, converting the retrieved additional content to an additional content data structure, and inserting the additional content data structure in the web page template to create the model view. Further, executing the API request to retrieve content and executing the additional API request to retrieve additional content can be executed in parallel.
These and other advantages, aspects, and features will become more apparent from the following detailed description when viewed in conjunction with the accompanying drawings. Non-limiting and non-exhaustive embodiments are described with reference to the following drawings. Accordingly, the drawings and descriptions below are to be regarded as illustrative in nature, and not as restrictive.
In the drawings, like reference numerals designate identical or corresponding parts throughout the figures.
A chain of executor context decorators can be configured that will be used by the controller. This will force the controller to use the configured decorators instead of the default list.
Requestors 208a, 208b, 208c can build an API URI from the configured request parameters. Requestors 208a, 208b, 208c then send a request to the API with the built URL and gets response data back. Requestors 208a, 208b, 208c can take the following configuration properties:
name: The name used to identify the requestor. It needs to be unique amongst the requestors used for a given page.
urlBase: The base URL of the request. This value can be optional, as the class can have hard-coded default of the current version of the internal API. By adding this value, however, it is possible to control upgrades between API versions.
resourceName: The path to the REST (representational state transfer) resource being requested.
defaultParams: A map of the API querystring parameters to be included in all requests to the API. The parameter values can be statically configured, or dynamically generated at page-request time from properties of the request context or previous API responses. A missing default parameter value can result in a 404 HTTP page response without a call to the API (see Requestor Parameters).
optionalParams (optional): A map of optional parameters to be checked for at request time. If these parameters exist, they will be included in the API request.
requestorProperties (optional): A list of key/value pairs to be used to change the default behavior of the requestor. An example is shown below in the “Override” section. Another example is query.encode=false which turns off URL encoding on the query parameter.
A sample requestor configuration is shown below:
Each requestor 208a, 208b, 208c has a name associated with it and is statically mapped to a given API request bound to a given URI path. A requestor 208a, 208b, 208c can have both static and dynamic component parameters of the API request mapped to it. The dynamic components are determined at request time based on properties of the request itself, or the results contained in API requests mapped to other requesters invoked previously in the request handling flow. Parameters can have a statically defined default value that will be used, unless a dynamically defined value exists at request-time. In this example, OID: nodeId represents a dynamic parameter value, wherein the nodeId of the request URL's ontology ID will be used.
With the example configuration shown above, if the request URL to the application is this:
http://www.cnet.com/123-6501—7-123.html
Then the resulting API URL executed will be:
The default and optional parameters are ordered by the parameter names when they are added in the API URL. This enables the API server to better implement its caching functionalities.
Executor 216 executes a given action. Executor 216 can be an interface for a component that knows how to execute a given action. Examples of executor implementations include the requestor executors and group executors (not shown separately). Both examples can have sub-types as well. For example, a requestor executor can be a simple requestor executor that fires a single API request, or the requestor executor can be a conditional executor that can evaluate an expression and may or may not execute depending on the result of the evaluation. Group executor sub-types can include a serial executor that contains a group of child executors that fire in series. Additionally, the group executor can include a parallel executor that contains a group of child executors that fire in parallel.
Successful execution of an executor can be either required or optional for successful request processing. This can be determined by its OnFailureAction setting. If a required executor fails, subsequent executors will not be fired, and the application will return an error code, such as a configurable HTTP error code, which is configured in the controller. If an optional executor fails, the controller will ignore it and continue processing subsequent executors, and the request may still return a success state.
The OnFailureAction property of an executor can be:
FAIL: indicates the executor is required, will stop the chain of execution and result in an error state.
CONTINUE: indicates the executor is optional, will not stop the chain of execution
RETURN: indicates the executor is required, will force the chain of execution to return immediately.
The OnFailureAction value of a group executor depends on its child executors' OnFailureAction values.
If, however, there are pending executors that have not yet returned in block 712, the process continues to block 716, and the system polls for a response. If the response state is a fail condition in block 718, the process continues to block 722 where the system determines if the Onfail condition is continue. If the Onfail condition is continue, the process moves to block 710 where the system determines if there are additional executors. If there are no additional executors in block 710, the process continues to block 720 and returns a complete, and the process ends in block 790.
If however, there are additional executors in block 710, the process continues to block 714 where the next executor is executed. In block 718, the state is again determined, and the loop continues until there are no longer any executors in block 710 or the state does not equal fail in block 718 or the Onfail does not equal continue in block 722.
For example, if the state does not equal fail in block 718, the system checks if the state equals incomplete in block 725. If the state equals incomplete in block 725, the process returns an incomplete in block 728, and the process ends in block 790. If, however, the state does not equal incomplete in block 725, the process continues to block 735 where the system determines if the state equals complete. If the state does not equal complete, an exception is thrown in block 745, and the process ends in block 790. If, however, the state equals complete in block 735 the process moves to block 715 to check if another parallel or serial group executor exists. If a parallel group executor exists in block 715, the process moves to block 712 and progresses as described above. If a serial group executor exists in block 715, the process moves to block 710 and progresses as described above.
Once the Onfail does not equal continue in block 722, the process checks to see if the Onfail status is return in block 726. If the Onfail status is return, the process moves to block 728 and returns an incomplete, and the process ends in block 790. If the Onfail does not equal return in block 726, the process moves to block 730 and the system checks if the Onfail condition is fail. If the Onfail condition is fail, a fail is returned in block 734, and the process ends in block 790. If, however, the Onfail does not equal fail, the process moves to block 745 and throws an exception, and the process ends in block 790.
As an example, for a web page that offers products for sale with some reviews of the offered product, a developer can configure that a request should be made to an API to get a given product, followed by a request to get the editor reviews for the product, followed by two parallel requests to get the user reviews and the user comments associated with the product. The first two serial requests could be marked as required with a high timeout setting, while the final two parallel requests could be marked as optional with a low timeout setting. By doing this, the developer implies that the page cannot be rendered without the data from the initial two requests, but the page can also utilize data from the last two requests if it exists. In this example, the developer has configured the first two API requests to be executed in series, since response data from the first request (i.e. the product review id) is needed to build the request of the second request. If that were not the case, they could be configured to be executed in parallel. If the data associated with a non-required request is not in the APIs cache, the request might time out while the data is “pulled” into the cache by the timed-out requester. Subsequent requests to the API for the same data should then respond rapidly.
A requester executor is a wrapper around a requestor. Each requestor executor contains a single API requestor. The requestor executor passes to the requestor what is needed to build the request URL and fires it. In one example, a requestor executor is a component that knows how to make an API request to a given API for a configured requestor. This class determines the values for the dynamic components required by the requestor. The requestor executor can be configured to have a given timeout associated with the API request. The requestor executor will fail if the request to the API server does not return before the configured timeout.
A conditional executor is a special form of requestor executor. A conditional executor knows how to evaluate a key against a value, and based on the evaluation output decides whether to proceed or not. To configure a conditional executor, the conditionKey and conditionValue properties can be set such that the executor only gets executed when the key matches the value. If the value is numeric, a third property condition is used to define the relationship between the key and the value. The conditionKey can be any of the supported requestor parameters. A conditional executor can be either required or optional.
Each requestor executor can be configured with a timeout setting. A global timeout setting in the controller applies to the top-level group executor and can also be set on the controller. During execution, the time permitted for each requestor executor is taken as the minimum of either the requestor executor's configured timeout, or the time remaining until the global timeout is reached.
If the timeout of a single request executor is exceeded, the executor returns a FAILED state. If the overall execution time has exceeded the global timeout, the executor also returns a FAILED state. The executor timeout value is configured in each executor as timeout. The global timeout value is configured in each controller as globalTimeout.
Validators may be used to validate API requests and/or the responses. The API request is checked against a request validator before the execution of the executor. If the result is invalid, the controller will not execute the requestor. A response validator is checked against the API response after the execution but before the response is processed. If the result is invalid, the controller will not add the response to the context. OnFailureActions will be triggered if request or response validation fails.
Request handlers can be added to the controller to add pre/post handling logic. A pre-handler returns either true or false. Returning false indicates that the handling of the request has been completed by the handler. The controller will therefore not continue and will return null. A post-handler may add/modify the ModelAndView object returned by the controller.
As also shown in
In
Referring to
At block 410, a developer is provided with a parallel application program interface (API) client controller 202 to build a model view. A plurality of API paths are provided on an API storage device, such as a host server. The API paths provide a route to content. For example, an API path may include a uniform resource identifier (URI) denoting the location or address of a piece of content. In block 415, an example application program interface client controller 202 employs requestor 208 to map an API path to an API request. In this fashion, when an API request occurs, an API path to the content already exists. An API request may be an API call that pulls data from one location to make use of that data.
In block 420, executor device 216 executes the API request to retrieve content, represented as text response data (e.g. XML, JSON, etc.). The content served by the API may reside in any suitable memory device, such as in a cache, RAM, removable storage device, and the like. The content may also reside in a database, for example. Additionally, the content may reside in a database abstraction layer that unifies communication between application and database programs. In block 425, the content is retrieved. In block 430, converter device 212 converts the retrieved content to a content data structure. For example, the retrieved content may be converted from an XML format to a Java Map object. In block 435, the content data structure is inserted in a web page (view) template. The web page template used may be determined based upon a characteristic of the content data structure or other factors. In block 440, a model view is created based upon the inserted content data structure and the web page (view) template.
Using the above example, for a web page that offers products for sale with some reviews of the offered product, a developer can configure that a request should be made to an API to get a given product. That is, a developer can map an API path to the given product when an API request for that product is made by a requester device. An additional request can be made to get the editor reviews for the product, followed by two parallel requests to get the user reviews and the user comments associated with the product. Each API path is mapped to the respective API request. Additionally, the developer can specify that these first two (serial) requests should be marked as required with a high timeout setting, while the final two (parallel) requests could be marked as optional with a low timeout setting. That is, execution of the respective API requests can be stopped after a predetermined amount of time. By setting the requests in this fashion, the developer provides the controller with information that the page cannot be rendered without the data from the initial two requests (that is, the product itself and the editor review), but that the page can utilize data from the last two requests (user reviews and user comments) if that content exists. If the data associated with a non-required request is not in the API's cache or other accessible memory, the non-required requests might time out while the data is “pulled” into the cache by the timed-out requester. Subsequent requests to the API for the same data should then respond rapidly.
Once the content is retrieved, the converter device 212 converts the retrieved content to a content data structure suitable for use in a web page (view) template. The web page templates can be located on a host server, stored in a computer readable medium, or otherwise made accessible to the controller. The web page templates can be, for example, themes, visual layouts, text formats, and other template materials accessible, and combinations thereof.
Themes can be designs and styles for the web page that may control such attributes as font, font size, font color, content size, content layout, background color, headings, and the like, and combinations thereof. A user can create his or her own theme via a cascading style sheet (CSS) or other methods. Alternatively, a user can select a CSS design overlay or pre-built design/content page template from a library by selecting pre-built themes. A pre-built theme can be created and added to the library by a user to provide an outline for future web pages, or can be created and added by a user in the process of building a previous web page.
An example web page template 500 is shown in
As indicated above, multiple API requests can be executed to retrieve content. The requests can be executed in a serial fashion, or in a parallel manner. Respective executors are configured to fire serially, or in parallel. By combining serial group executors and parallel group executors, the system can configure control flow into the execution of numerous requestor executors. Once the developer configures how the controller will behave to build the model required by the web page view, future user input events can be serviced efficiently and effectively.
Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
Computer system 600 can include one or more computing machines capable of operating one or more web-based applications that can be accessed by network devices in the network 690, such as client devices, for example, and can provide other data representing requested resources, such as particular web page(s), image(s) of physical objects, and any other objects, responsive to the requests, although computer system 600 can perform other tasks and provide other types of resources.
Computer system 600 includes processor 650 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), main memory 660 (e.g., read only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.) and static memory 670 (e.g., flash memory, static random access memory (SRAM), etc.), which communicate with each other via bus 695.
Computer system 600 may further include video display unit 610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Computer system 600 also includes alphanumeric input device 615 (e.g., a keyboard), cursor control device 620 (e.g., a mouse), disk drive unit 630, signal generation device 640 (e.g., a speaker), and network interface device 680.
Disk drive unit 630 includes computer-readable medium 634 on which is stored one or more sets of instructions (e.g., software 638) embodying any one or more of the methodologies or functions described herein. Software 638 may also reside, completely or at least partially, within main memory 660 and/or within processor 650 during execution thereof by computer system 600, main memory 660 and processor 650 also constituting computer-readable media. Software 638 may further be transmitted or received over network 690 via network interface device 680.
While computer-readable medium 634 is shown in an exemplary embodiment to be a single medium, the term “computer-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “computer-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media.
Having thus described the basic concept of the invention, it will be rather apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented by way of example only, and is not limiting. Various alterations, improvements, and modifications will occur and are intended to those skilled in the art, though not expressly stated herein. These alterations, improvements, and modifications are intended to be suggested hereby, and are within the spirit and scope of the invention. Additionally, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations therefore, is not intended to limit the claimed processes to any order except as can be specified in the claims. Accordingly, the invention is limited only by the following claims and equivalents thereto.
This application claims the benefit of U.S. Provisional Application No. 61/291,510, filed Dec. 31, 2009, the disclosure of which is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61291510 | Dec 2009 | US |
