Patent Application
20090254926
A network application, such as a Web application, is typically accessible to users via a client application. The client may be implemented as part of, or alongside, the Web application. Alternately, the developer of the Web application can publish, or make available, an application programming interface (API) so that other developers can create clients for the Web application. Some clients are standardized to particular formats, such as Really Simple Syndication (RSS) or ATOM Syndication (ATOM).
There are two components of an API: an abstraction component and an implementation component. The abstraction component is essentially a document (or series of documents) that describes to a developer how to write source code to interface with the Web application. The implementation component is executable code that acts as the interface between clients written to the API and the Web application itself.
Described herein are implementations of various technologies for registering a network application with an application programming interface (API) framework. In operation, a registrar may send a registration message that associates a namespace with the network application to the API framework. In one implementation, the namespace associated with the network application may be a uniform resource identifier. In another implementation, the registration message may specify a format of the standardized clients, a security policy, and the application resources associated with the network application.
The registrar may then store create, read, update, and delete (CRUD) methods for an application resource associated with the network application. The CRUD methods may be configured to be invoked by a request from the API framework. In one implementation, the request from the API framework may be a representational state transfer (REST) or SOAP request.
In response to receiving the registration message, the API framework may create an API associated with the network application. In one implementation, the network application may be a Web application.
The above referenced summary section is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description section. The summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.
In general, one or more implementations of various technologies described herein are directed to registering network applications with an application programming interface (API) framework. A registrar may initiate the registration process by sending a message that associates a namespace with the network application to the API framework. The registrar may store create, read, update, and delete (CRUD) methods for an application resource associated with the network application. In response, the API framework may create an API associated with the network application. As a result, developers may then write standardized clients for the network application by simply using the API created by the API framework.
Implementations of various technologies described herein may be operational with numerous general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the various technologies described herein include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The various technologies described herein may be implemented in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The various technologies described herein may also be implemented in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network, e.g., by hardwired links, wireless links, or combinations thereof. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
The client computer 102 may include a central processing unit (CPU) 104, a system memory 106 and a system bus 117 that couples various system components including the system memory 106 to the CPU 104. It should be noted that the CPU 104 may include Virtualized systems (Virtual Machines, Processors), as well as CPU Cores and Hyper-threaded processors within a physical CPU. Although only one CPU is illustrated in
The client computer 102 may further include a storage 108, which may be connected to the bus 117. Examples of storage 108 include a hard disk drive for reading from and writing to a hard disk, a magnetic disk drive for reading from and writing to a removable magnetic disk, and an optical disk drive for reading from and writing to a removable optical disk, such as a CD ROM or other optical media. The storage 108 and associated computer-readable media may provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the client computer 102.
It should be appreciated by those skilled in the art that the client computer 102 may also include other types of storage 108 and associated computer-readable media that may be accessed by a computer. For example, such computer-readable media may include computer storage media and communication media. Computer storage media may include volatile and non-volatile, and removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules or other data. Computer storage media may further include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid state memory technology, CD-ROM, digital versatile disks (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the client computer 102. Communication media may embody computer readable instructions, data structures, program modules or other data in a modulated data signal, such as a carrier wave or other transport mechanism and may include any information delivery media. The term “modulated data signal” may mean a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above may also be included within the scope of computer readable media.
A number of program modules may be stored in memory 106, including an operating system 112, a standardized client 114, and a development kit 116. The operating system 112 may be any suitable operating system that may control the operation of a networked personal or server computer, such as Windows® Vista, Mac OS® X, Unix-variants (e.g., Linux® and BSD®), and the like. The standardized client 114 may be software that presents information about a Web application 155 and resources 156 (both stored on application server 142) to a user, where the client 114 is standardized to a particular format. Examples of standardized formats include really simple syndication (RSS), ATOM Syndication, ATOM Publishing Protocol (APP), JavaScript Object Notation (JSON), extensible markup language (XML), and binary XML. In one implementation, the standardized client 114 is an RSS reader.
Typically, a software engineer downloads a copy of the development kit 116 from the API framework server 122 to the client 102. The development kit 116 may include a set of development tools that enables the software engineer to create the standardized client 114. The development tools may include code editors, debugging aids, and other utilities often presented in an integrated development environment. Using the development kit 116, the software engineer may create source code (not shown), compile the source code, and link the compiled code to generate the standardized client 114.
In one implementation, the development kit 116 may communicate with an API framework 135 (stored on the API framework server 122) to determine some of the parameters required to access the Web application 155 and associated resources 156. The development kit 116 may present the parameters to the software engineer. Accordingly, the software engineer may incorporate the requisite parameters into the source code for the standardized client 114.
A user may enter commands and information into the client computer 102 through an input device 118. Examples of input devices 118 include keyboards, pointing devices, microphones, joysticks, game pads, satellite dishes, scanners, or the like. These and other input devices may be connected to the CPU 104 through the system bus 117. A user may receive information from the client computer 102 via an output device 119. Examples of output devices 119 include displays, speakers, printers, and fax machines.
The client computer 102 may be connected to the network 160 through a network interface 110. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
The API framework server 122 and application server 142 may be similarly constructed as the client computer 102. The API framework server 122 may contain a CPU 124, system memory 126, storage 128, and network interface 130. Similarly, the application server 142 may contain a CPU 144, system memory 146, storage 148, and network interface 150.
At the application server 142, the system memory 146 may include an operating system 152 and a registrar 153. The registrar 153 may be software that makes the Web application 155 accessible to the standardized client 114 via the API framework 135. In one implementation, the registrar 153 may send a registration message to the API framework 135. In response, the API framework 135 may create an API 138 for the Web application 155. Additionally, the registrar 153 may store resource methods 154 on the application server 142. The resource methods 154, when invoked, may access/update the resources 156 associated with the Web application 155. The registrar 153 will be described in greater detail in the description of
The storage 148 may include the Web application 155, resource methods 154 and resources 156. The Web application 155 may be software for sharing and managing resources 156 for users of clients 102. Examples of Web applications 155 include Weblogs (blogs), discussion boards, e-mail programs, and software for sharing media, such as photographs. In one implementation, the Web application 155 may be a Web service.
It should be noted that the Web application 155 is merely a specific example of a network application, and that any application accessible via a hypertext transfer protocol (HTTP) or HTTP over Secure Socket Layer (HTTPS) may be used in various implementations described herein.
Each resource 156 may be associated with and managed by a particular Web application 155. The resources 156 managed in the example Web applications include blog or discussion board posts, e-mails, e-mail folders, and the photographs or other media shared. Those skilled in the art recognize that a wide array of Web applications 155 and resources 156 are possible, and these examples are provided for purposes of illustration and are not intended to be limiting.
Each resource method 154 may perform one create, read, update, or delete (CRUD) operation for one or more of the resources 156 of an associated Web application 155. Resource methods 154 on the application server 142 may be invoked by the API framework 135 based on the registered API 138 for the associated Web application 155. The API framework 135 and API 138 will be described in more detail in the paragraphs below with reference to the API framework server 122.
In one implementation, the API framework 135 may invoke the resource methods 154 using a representational state transfer (REST) request to the Web application 155. REST is an architectural methodology for distributed hypermedia systems such as the World Wide Web. REST describes any simple interface that transmits domain-specific data over hypertext transfer protocol (HTTP) without an additional messaging layer.
Typically, a REST request uses the standard GET, POST, PUT, DELETE semantics of HTTP. It should be noted that other REST operations, such as HEAD (an optimized GET operation), and yet to be developed operations may be accommodated in various implementations described herein. Further, REST is merely one example of a methodology for sending application resource requests from the API framework server 122 to the application server 142. It should be noted that other methodologies/protocols, such as SOAP or binary may be used for requests to invoke resource methods 154 in various implementations described herein.
Referring now to the API framework server 122, the system memory 126 may include an operating system 132 and the API framework 135. The API framework 135 may include one or more APIs 138. The APIs 138 may specify Web applications 155 available to standardized clients via the API framework 135. Further, each API 138 may specify how the standardized client 114 may interact with the Web application 155 and associated resources 156.
The API framework 135 may be software that provides access to the Web application 155 for the standardized client 114. In one implementation, the API framework 135 may initiate requests for access to the Web application 155 and/or resources 156 in response to hypertext transfer protocol (HTTP) requests from the standardized client 114. Additionally, the API framework 135 may create the API 138 for the Web application 155 in response to a registration request from the registrar 153.
In another implementation, the API framework 135 may invoke resource methods 154 corresponding to the request from the standardized client 114 and receive a response from the Web application 155. Further, the API framework 135 may translate the response from the Web application 155 into the format used by the standardized client 114 and send the translated response to the standardized client 114.
While the computing system 100 illustrates the API framework server 122 and application server 142 as separate computers, it should be understood that in some implementations, the functionalities performed by the API framework server 122 and the application server 142 may be performed by a single computer. For example, the Web application 155, resource methods 154, and resources 156 may be alternatively stored in the storage 128.
As shown, a Web application server 242 may have more than one Web application 255. Some examples of Web applications 255 include an address book 210, a photo sharing application 220, and a blogs application 230. Each application 255 has access to different types of resources 256. In one implementation, resources 256 can include data 260 and organizational-type resources, such as libraries 258. For example, the photo sharing application 220 may organize photos 224 (and associated comments 226) into albums 222. Similarly, the blogs application 230 may organize posts 234 and comments 236 into different blogs 232.
In another implementation, an application, such as the address book 210, may access data 260 without the use of libraries 258. For example, the address book 210 may access data 260, such as a person 214, by using other data 260 available to the address book 210, such as a category 212, and a person reference 216. In such a scenario, the person reference 216 may represent a pointer to each person 214 in a particular category 212.
In a system that publishes Web applications 155 to standardized clients 114, resource methods 154 may be stored on the application server 142 for each resource 256. Accordingly, in the example shown, resource methods 154 (one each for CREATE, READ, UPDATE, and DELETE) are stored for the album 222 and blog 232 libraries. The resource methods 154 are also stored for each of the category 212, person reference 216, person 214, photo 224, comments 226, post 234, and comments 236 data.
As shown, the method 300 begins at step 305 when the registrar 153 sends a registration message for each Web application 155 to the API framework 135. The registration message may include a namespace, the uniform resource identifier (URI) of the web application 155, and the formats for standardized clients 114 to which the Web application 155 is to be made accessible. Additionally, the registration message may specify the resources 156 associated with the registered Web application 155.
The namespace is an identifier by which the API framework 135 associates client requests for the Web application 155 with the Web application 155. The URI identifies the location of the web application 155. The formats may include any standardized format such as really simple syndication (RSS), ATOM Syndication, JavaScript Object Notation, extensible markup language (XML), or binary XML. The formats described herein are mere examples and are not intended to be limiting. Those skilled in the art appreciate that other formats, known or yet to be developed, may be used in various implementations described herein.
In one implementation, the registration message may include a security policy. The security policy may specify one or more rules for restricting client access to the Web application 155 and/or the associated resources 156. The security policy may be recorded in the API 138.
At step 310, the registrar 153 may determine all the resources 156 associated with the Web application 155 for which the registration message is sent. For example, all the resources 256 associated with the photo sharing application 220 include the album library 222, the photo data 224, and the comment data 226.
Steps 315-325 may be repeated for each resource 156 associated with the Web application 155. At step 320, the registrar 153 may create resource methods 154 for the resource 156. The resource methods 154 may include create, read, update, and delete (CRUD) methods for each resource 156. At step 325, the registrar 153 may store the resource methods 154 on the application server 142. As such, in response to client requests, the API framework 135 may create, read, update and delete resources 156 by invoking the stored resource methods 154.
Advantageously, developers of standardized clients 114 may consume numerous Web applications 155 registered in a centralized API framework 135. Without the centralized APIs 138 provided by the API framework 135, developers would have to develop clients to consume applications according to the varying models of APIs provided by the individual Web applications.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
