US20140244708A1 - Backwards-compatible feature-level version control of an application using a restlike api - Google Patents

Backwards-compatible feature-level version control of an application using a restlike api Download PDF

Info

Publication number
US20140244708A1
US20140244708A1 US13/927,112 US201313927112A US2014244708A1 US 20140244708 A1 US20140244708 A1 US 20140244708A1 US 201313927112 A US201313927112 A US 201313927112A US 2014244708 A1 US2014244708 A1 US 2014244708A1
Authority
US
United States
Prior art keywords
resource
client
instance
application
version
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/927,112
Inventor
Stephane Taine
Deepak Rao
Shahzaib Younis
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US201361771073P priority Critical
Application filed by Microsoft Corp filed Critical Microsoft Corp
Priority to US13/927,112 priority patent/US20140244708A1/en
Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: RAO, DEEPAK, TAINE, STEPHANE, YOUNIS, SHAHZAIB
Publication of US20140244708A1 publication Critical patent/US20140244708A1/en
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MICROSOFT CORPORATION
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MICROSOFT CORPORATION
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0807Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00
    • H04L29/02Communication control; Communication processing
    • H04L29/06Communication control; Communication processing characterised by a protocol
    • H04L29/08Transmission control procedure, e.g. data link level control procedure
    • H04L29/08081Protocols for network applications
    • H04L29/08135Protocols for network applications in which application tasks are distributed across nodes in the network
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates
    • G06F21/335User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/40Services or applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/02Network-specific arrangements or communication protocols supporting networked applications involving the use of web-based technology, e.g. hyper text transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/10Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/10Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network
    • H04L67/1095Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network for supporting replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes or user terminals or syncML
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/28Network-specific arrangements or communication protocols supporting networked applications for the provision of proxy services, e.g. intermediate processing or storage in the network
    • H04L67/2814Network-specific arrangements or communication protocols supporting networked applications for the provision of proxy services, e.g. intermediate processing or storage in the network for data redirection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/32Network-specific arrangements or communication protocols supporting networked applications for scheduling or organising the servicing of application requests, e.g. requests for application data transmissions involving the analysis and optimisation of the required network resources
    • H04L67/327Network-specific arrangements or communication protocols supporting networked applications for scheduling or organising the servicing of application requests, e.g. requests for application data transmissions involving the analysis and optimisation of the required network resources whereby the routing of a service request to a node providing the service depends on the content or context of the request, e.g. profile, connectivity status, payload or application type

Abstract

Client and server-side instances of an application leverage an application programming interface (API) that complies with a representational state transformation architecture and supports backwards-compatible feature-level version control. A resource maintained by the server-side instance of the application is revised independent of revisions of a remainder of the application. The server-side instance of the application maintains multiple versions of a resource and/or a resource that is a superset of revisions of the resource, such that a compatible version of the resource is served to the client-side instance of the application.

Description

    RELATED APPLICATION
  • This application claims priority to U.S. Provisional Patent Application No. 61/771,073, filed Feb. 28, 2013, and entitled “UNIFIED COMMUNICATIONS TECHNOLOGIES,” the entirety of which is incorporated herein by reference.
  • BACKGROUND
  • A distributed application is software that executes on two or more computers in a network, wherein such computers can communicate with one another over the network. Generally, in a client-server environment, a distributed application has two portions: 1) a “front end” that executes on a client computing device(s); and 2) a “back end” that executes on a server computing device(s). An instance of the distributed application executing on a client computing device is referred to herein as a “client”, while an instance of the distributed application executing on a server computing device is referred to herein as a “server.” A distributed application can use an application programming interface (API) to provide a common interface for communications between different executing instances, and can be used to provide services, features, and information in a way that can be understood by application developers and used by different executing instances of the application.
  • Web Application Program Interfaces (APIs) conventionally employed with distributed applications use link-relations to express capabilities supported by a server, wherein the use of link-relations conforms to the HATEOAS (Hypertext as the engine of application state) principle. New capabilities can be introduced by adding new link-relations; however, in conventional approaches, this negatively impacts backward compatibility.
  • For example, a modification made to a server may be a breaking change, in that the modification may cause a client to be incompatible with the server. In another example, a modification made to a client may be a breaking change, in that the modification causes the client to be incompatible with another client (e.g., a legacy client). For instance, when the server is changed such that it is incompatible with a client, the client will be unable to fully interact with the server.
  • In another example, a modification made to a server may be a non-breaking change, but such modification may nevertheless cause undesirable results. Modifying a distributed application with non-breaking changes can result in bloated clients that comprise unsupported or unused services and data. For example, client-side discovery of how a server has been updated may be difficult or impossible, as changes may only be indicated, if at all, in complex documentation that does not facilitate rapid integration of new features. Additionally, there is no mechanism for isolated feature version control in many conventional APIs, and thus it is difficult to implement non-breaking changes for distributed applications without making undesirable development sacrifices.
  • Furthermore, significant changes to a distributed application can require a version of a client or a server to be updated, wherein the updated version breaks previous versions and hinders backwards-compatibility. Such changes not only create interruptions of service, but also require a significant development investment. Additionally, developing a complete new version can take significantly more time than making isolated changes, and thus also impedes a rate at which new features are developed for the distributed application.
  • SUMMARY
  • The following is a brief summary of subject matter that is described in greater detail herein. This summary is not intended to be limiting as to the scope of the claims.
  • Various technologies pertaining to an application programming interface (API) that generally complies with a representational state transfer (REST) architecture are described herein. Such an API provides support for backwards-compatible feature-level version control of a distributed application.
  • An application distributed between one or more client computing devices and server computing devices (a distributed application) can use the aforementioned API in connection with updating the distributed application. In an exemplary embodiment, such distributed application can be a unified communications (UC) application, an e-commerce application, a social-networking application, some other application, or a combination thereof. A system architecture that supports the distributed application includes client computing devices in communication with server computing devices, where the client computing devices execute client-side instances of the application (clients) and the server computing devices execute server-side code (servers). The client computing devices may include desktop computing devices as well as portable computing devices such as mobile telephones, tablets (slates), phablets, wearables, etc. In accordance with aspects described herein, a UC application can use the API to support real-time synchronous communication between clients and/or between a client and a server. Moreover, the UC application can additionally support asynchronous communication in real time or near-real time (e.g., a matter of microseconds). It is to be understood that the API generally complies with the REST architecture (e.g., the API is a RESTlike API).
  • The API is modeled using identifiers and commands, where the identifiers represent resources and the commands represent methods of interacting with resources, such as conventional hypertext-transfer-protocol (HTTP) methods and hypermedia types. A resource can be or include data, such as a document, image, database entry, etc. In another example, a resource can be or include computer-executable code, such as a service, an executable thread, etc. Furthermore, resources generally pertain to a particular concept described by their respective identifiers. For example, a “contacts” resource can include a list of contacts of a user, or can be a service that retrieves the list of contacts from other resources. Each resource is identified by a respective identifier that can be used by the client to access a respective resource. For example, the identifier can be a global identifier (e.g., such as a universal resource locator (URL)), or can be a relative identifier that is specific to the application. Resources can also comprise identifiers of other resources, so as to indicate a link-relation between resources. For example, a “features” resource can also comprise an identifier of a “contacts” resource that comprises a list of contacts of the user, thus indicating that the contacts list is a feature of the application. The client, after accessing the “features” resource and locating the identifier for the “contacts” resource, can then use the identifier for the “contacts” resource to retrieve the list of the contacts. Such link-relations can allow a client to navigate through resources in a manner that is similar to how a user can navigate through webpages using hyperlinks.
  • As noted above, the commands represent respective methods of interacting with resources. Exemplary methods include methods compatible with the HATEOAS principle. By combining an identifier and a command in a request, a client can identify a resource that is desirably accessed as well as an operation that is desirably executed. For example, in order to retrieve a list of contacts of a user, a client can generate a request that includes a command representing a retrieval operation and an identifier representing the “contacts” resource. Certain resources can be referred to as “endpoints”, where a defined set of actions can be undertaken on such endpoints. In response to the request, the server can transmit a reply to the client that comprises the resource, a data packet comprising data from the resource, and or other information about the requested resource.
  • A RESTlike Web API that supports feature-level revision while also supporting backwards compatibility is described herein. Such a RESTlikeWeb API provides an interface between clients and/or servers that allows different versions of clients and/or servers to be compatible with one another. Servers can use the API to discover features that a client can support, and can provide such features in a format that the client can understand. A client can use the API to discover when a feature supported by the client has been revised on a server; accordingly, a developer can adapt the client to support new features without necessitating a completely new version of the client or perusal of complex documentation.
  • The RESTlike API can further support addition of new features (functionality) in a manner that does not require the creation of new resources. Rather, a resource can be revised, and such revision can be recognized by the client. A version of a resource can be a superset of all previous versions/revisions of the resource. For example, a second version of a resource can comprise an original version of the resource and a revision. Since a version of a resource is a superset of previous versions, the resource is backwards compatible. Thus, although the resource has been revised (e.g., to be a second version of the resource), the original version of the resource (with which a client is compatible) remains available to the client.
  • Furthermore, a client can request that the server deliver either a minimum version of a resource or a particular version of a resource with which the client is compatible. The server can also be configured to determine a version of the client that sends a request to the server, and the server can then transmit resources to the client that are compatible with the version of the client. Thus, clients and servers can be kept apprised of the other's respective version so as to maintain compatibility.
  • When breaking changes, or changes that would cause a server or a client to be incompatible with another client, are desirably made to a distributed application, versions of resources can be maintained independently. For example, a “contacts” resource can include a list of contacts in alphabetical order, and can be modified to include the list of contacts in order of time of communications. The modified resource may be incompatible with the client, and thus the server can maintain a first version of the resource (where the contacts are listed in alphabetical order) and can also maintain a second version of the resource (where the contacts are listed based upon time of communications with a user of the client).
  • Along with transmitting information about resources that are available to the client, the server can also transmit other information about the resources, such as whether a resource has been revised, a version of the resource, an indication that the resource is to be deprecated, and other information that may be relevant to the client. For example, a developer may wish to make a breaking change to a resource that is being used by the client (e.g., a particular version of the client). The developer can include information with the resource that the resource is to be deprecated in, for example, three months. Developers for the client are therefore informed of the breaking change, and can implement support for the breaking change prior to the three month deadline.
  • Because modifications to resources that are accessible by the client, modifications to the server, as well as other information such as when a resource is to be deprecated, can be recognized by the client, developers of the client are supplied with information that facilitates expedient implementation of new functionalities. Developers of the client are informed as to what features have been modified (and how such features have been modified) without having to consult application documentation and without having to rewrite the client.
  • As the RESTlike API provides backwards-compatible feature level version control, the modifications to the client and/or server need not happen contemporaneously. In some circumstances, the client and/or server may be developed by different developers or may be executed by different entities, such that a single entity may not have control over both a client and server. By offering backward-compatible feature level version control, modifications can be made to the application in a way that does not negatively impact existing clients.
  • The above summary presents a simplified summary in order to provide a basic understanding of some aspects of the systems and/or methods discussed herein. This summary is not an extensive overview of the systems and/or methods discussed herein. It is not intended to identify key/critical elements or to delineate the scope of such systems and/or methods. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIGS. 1 and 2 are functional block diagrams of respective exemplary systems that facilitate executing an application that supports backwards-compatible feature-level version control through use of a RESTlike API.
  • FIG. 3 is a flow diagram that illustrates an exemplary methodology that facilitates backwards-compatible feature-level version control of a distributed application through use of a RESTlike API at a client computing device.
  • FIGS. 4 and 5 are flow diagrams that illustrate respective exemplary methodologies for retrieving a resource maintained by a server-side instance of a distributed application.
  • FIG. 6 is a flow diagram that illustrates an exemplary methodology for determining that a resource has been revised.
  • FIGS. 7 and 8 are flow diagrams that illustrate respective exemplary methodologies for retrieving a resource maintained by a server-side instance of a distributed application.
  • FIG. 9 is a flow diagram that illustrates an exemplary methodology for providing a client-side instance of a distributed application with a compatible version of a resource.
  • FIG. 10 is a flow diagram that illustrates an exemplary methodology for modifying a resource and providing the modified resource to a client-side instance of a distributed application.
  • FIG. 11 is an exemplary computing system.
  • DETAILED DESCRIPTION
  • Various technologies pertaining to backwards-compatible feature-level version control in a distributed application through use of an API that complies with the representational state transfer (REST) architecture are now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects. It may be evident, however, that such aspect(s) may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing one or more aspects. Further, it is to be understood that functionality that is described as being carried out by certain system components may be performed by multiple components. Similarly, for instance, a component may be configured to perform functionality that is described as being carried out by multiple components.
  • Moreover, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise, or clear from the context, the phrase “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, the phrase “X employs A or B” is satisfied by any of the following instances: X employs A; X employs B; or X employs both A and B. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from the context to be directed to a singular form.
  • Further, as used herein, the terms “component” and “system” are intended to encompass computer-readable data storage that is configured with computer-executable instructions that cause certain functionality to be performed when executed by a processor. The computer-executable instructions may include a routine, a function, or the like. It is also to be understood that a component or system may be localized on a single device or distributed across several devices. Further, as used herein, the term “exemplary” is intended to mean serving as an illustration or example of something, and is not intended to indicate a preference.
  • With reference now to FIG. 1, an exemplary system 100 that facilitates backwards-compatible feature-level version control in a distributed application is illustrated. The system 100 includes a plurality of client computing devices 102-104. The client computing devices 102-104 can include desktop computing devices, laptop computing devices, netbooks, ultrabooks, tablets (slates), phablets, mobile telephones, wearables, etc. The system 100 further includes a server computing device 106, which is in communication with the client computing devices 102-104 by way of suitable respective network connections. Additionally, communications channels can be established directly between computing devices in the client computing devices 102-104.
  • The client computing devices 102-104 and the server computing device 106 are configured to support backwards-compatible feature-level version control of a distributed application, wherein the client computing devices 102-104 execute respective client-side (front-end) instances of the distributed application and the server computing device executes a server-side instance (back-end) of the application. With more particularity, the first client computing device 102 includes a first processor module 108 that executes instructions retained in a first memory 110. The first memory 110 can include a first client-side instance of an application, referred to as a first client 112. Similarly, the Nth computing device 104 can include an Nth processor module 114 that is configured to execute instructions in an Nth memory 116. The Nth memory 116 includes an Nth client-side instance of the application, referred to as an Nth client 118.
  • The server computing device 106 includes a server processor module 120 that is configured to execute code in a server-side memory 122. For example, the server-side memory 122 can include server-side code (e.g., back end code) of the distributed application, wherein the server-side code is referred to herein as a server 124. In an exemplary embodiment, the distributed application can be a communications application that supports bi-directional communications between the client computing devices 102-104. For instance, the communications application can be a unified communications (UC) application, which supports multiple communications modalities, including voice, presence, instant messaging, groups, desktop sharing, collaboration, and the like. In another example, the communications application can be or be included in a social networking application.
  • As new features are developed for the distributed application, it may be desirable to modify the server 124 or at least one of the clients 102-104 to support such features. For example, the distributed application can be updated to support a feature, wherein the server 124 is modified to maintain additional data/code, and wherein the client 112 is desirably modified to remain compatible with the server 124. Through utilization of the RESTlike API, different versions of resources used by the distributed application can be maintained, different versions of clients and/or servers can be maintained, etc. Further, backwards-compatible feature-level version control can be provided, wherein individual features offered by the distributed application can be revised independent of a remainder of the distributed application. Thus, in an example, modifying the server 124 need not impact the compatibility of the first client 112 with the server 124.
  • As indicated above, the distributed application may be a communications application, and the first client 112 can cause a graphical user interface (GUI) to be displayed on a display screen (not shown) of the first client computing device 102, wherein the GUI includes, for example, contacts for a user of the first client 112, messages received by the first client 112, etc. Likewise, the server 124 can access a listing of contacts of the user, messages sent and received via the first client 112, and other data, which is used to populate the GUI. When the user of the first client computing device 102 seeks to send a communication to a contact (e.g., the user of the Nth client computing device 104), the first client 112 can communicate with the Nth client 118 via the server 124 or via a channel established by the server 124. The server 124, in addition to routing the communication, can also send other information to the first client 112 in real-time, such as that the contact is available to receive messages.
  • As will be described in greater detail herein, the RESTlike API is modeled in terms endpoints, which are resources upon which certain actions can be undertaken. Resources are represented by respective identifiers, and actions (e.g., methods of interacting with resources) are represented by commands, such as conventional hypertext-transfer-protocol (HTTP) methods and hypermedia types. For example, a resource including a contacts list can be an endpoint, and retrieval of such list can be supported. Accordingly, a resource can be or include data, such as a document, an image, etc. Additionally, a resource can be or include a computer-executable service that comprises computer-executable instructions that cause the server 124 to communicate with other computing devices. Further, a resource can be or include a combination of data and computer-executable instructions. Additionally, each resource can be directed towards a respective concept described by its identifier. For example, a “contacts” resource can include a list of contacts of a user.
  • Identifiers can be global identifiers, such as a universal resource locator (URL), or can be relative identifiers specific to the distributed application. A resource can also comprise an identifier of another resource (or multiple resources), so as to indicate a link-relation between the resource and the another resource. For example, a “features” resource can also comprise a link-relation to a “contacts” resource; e.g., the “features” resource can comprise an identifier of the “contacts” resource, wherein the contacts resource comprises a list of contacts of the user. The first client 112, after accessing the “features” resource (e.g., from the server 124) and locating the identifier for the “contacts” resource therein, can then use the identifier for the “contacts” resource to access the list of contacts. Such link-relations can allow the first client 112 to navigate through resources in a manner that is similar to how a user can navigate through webpages using hyperlinks.
  • A particular resource of the distributed application can be an entry endpoint for the application, and can include link-relations to other resources. For example, a client with information only of the entry endpoint “features” resource can navigate to the features resource in order to retrieve link-relations comprised by the “features” resource, and thereby learn what resources are available for the client. Thereafter, the client can navigate to resources identified in the link-relations.
  • Referring now to FIG. 2, an exemplary system 200 that facilitates backwards-compatible feature-level version control through utilization of a RESTlike API is illustrated. The system 200 comprises the first client 112 that is in communication with the server 124 through utilization of the RESTlike API. In another embodiment, the server 124 can be replaced with the Nth client 118, such that the first client 112 and the Nth client 118 are in direct communication with one another. The RESTlike API, as noted above, is modeled using identifiers and commands. Such identifiers and commands can be universal, in that they may be used without regard to a specific application being executed, a specific device being communicated with, or a specific operation being undertaken, and thus provide a generalized interface between devices.
  • Resources corresponding to the RESTlike API are now described. As shown, the server 124 can comprise or have access to a plurality of resources (e.g., a first resource 202 through an Mth resource 204). The format of a resource is arbitrary, as a resource can be structured as a database, a file, etc. Identifiers can respectively represent the resources 202-204, wherein a resource can comprise at least one of data (such as a document, an image, a database entry or entries, etc.), computer-executable code, or the like. Each resource pertains to a respective concept (e.g., which can be described by an identifier for the resource).
  • A resource can also comprise identifier(s) of other resource(s), so as to indicate a link-relation to the other resource(s). For example, the first resource 202 can be a “features” resource, and thus may comprise a listing of link-relations for resources available to the first client 112, including a link-relation to the Mth resource 204. For example, the Mth resource 204 can be a “contacts” resource, which is linked to by the “features” resource as follows:
  • link rel Href contacts http://example.com/features/contacts

    where “link rel” refers to relative identifiers and labels the link-relation “contacts,” thus being a relative identifier of the “contacts” resource (e.g., the Mth resource 204). “href” refers to global identifiers, where “http://example.com/features/contacts” is a global identifier of the “contacts” resource.
  • The server 124 can additionally maintain multiple versions/revisions of a resource, wherein a first revision of a resource can also be referred to as a second version of the resource, a second revision being a third version, and so on. It is to be understood that a version of a resource can be a superset of all previous versions of the resource; thus, a second version of a resource includes the first version of the resource and a revision to the first version of the resource. Each resource 202-204 can have a respective revision attribute, which can be used to identify a most current version as well as available versions that are available to the first client 112 (and other clients) by way of methods supported by the RESTlike API. The server 124 can maintain a first version 206 of the first resource 202 through a Jth version 208 of the first resource 202. Similarly, the server 124 can maintain a first version 210 of the Mth resource 204 through a Kth version 212 of the Mth resource 204. The server 124 can maintain multiple versions of a resource in a variety of manners. For example, the server 124 can separately maintain each version.
  • In an example, a version of a resource can be a superset of previous versions of the resource; however, separately maintaining multiple versions may involve maintaining redundant data (e.g., the first version 206 of the first resource 202 that is common to both the first version 206 of the first resource 202 and the Jth version 208 of the first resource 202). Accordingly, the first versions 206 and 210 of the resources 202-204 can be maintained, and other versions of the resources 202-204 can be revisions that can be appended to the first versions 206 and 210 of the resources 202-204. For example, rather than maintaining the first version 206 of the first resource 202 and a second version (not shown) of the first resource 202, the server 124 can maintain the first version 206 of the first resource 202 and a revision that modifies the first version 206 of the first resource 202 (e.g., thereby forming the second version of the first resource 202 while also retaining the first version 206 of the first resource 202). Thus, revisions can be appended to resources.
  • Methods supported by the RESTlike API (represented by commands) for interacting with resources are now described. Exemplary methods supported by the RESTlike API include conventional hypertext-transfer-protocol (HTTP) methods and hypermedia types. Thus, with more specificity, exemplary methods include a method for retrieving data from a resource (e.g., via a “GET” command), a method for adding data to a resource (e.g., via a “POST” command), a method for replacing or adding a resource (e.g., via a “PUT” command), and a method for deleting a resource (e.g., via a “DELETE” command). The first client 112 can generate a request that includes an identifier and a command, thereby identifying a resource that is desirably accessed and a method to be executed in connection with the resource. Accordingly, the first client 112 comprises a requester component 214 that is configured to access a resource in the resources 202-204 by sending a request to the server 124 that comprises an identification of a method (such as a method for retrieving data from a resource) and an identification of a global identifier of the resource that is desirably accessed.
  • For example, the first client 112 can navigate to an entry endpoint of the application by causing the requester component 214 to retrieve a list of resources available to the first client 112. For instance, the first client 112 can navigate to an entry endpoint of the application by requesting a “features” resource that comprises a list of resources that are available to the first client 112. The requester component 214 can transmit the following as a request for the first resource 202:
      • GET http://example.com/features/
        where “GET” identifies the method for retrieving data, and where “http://example.com/features” is a global identifier that identifies the first resource 202 (the entry endpoint).
  • Responsive to receiving the request for the first resource 202 from the first client 112, the server 124 can transmit a reply to the request to the first client 112, wherein the reply includes the first resource 202. In another example, the server 124 can generate a data packet based upon content of the first resource 202, and the reply can include such data packet. For example, such data packet may be smaller in size when compared to the size of the first resource 202. Additionally, the data packet may be in a format that is more readily parsed by the first client 112 when compared to the format of the first resource 202. The data packet can also comprise additional information pertaining to the distributed application, such as, for example, data identifying a version of the server 124, data identifying a resource as a resource that is to be deprecated, etc.
  • In an example, the data packet can be or include a document, a listing, or the like, and may be in a structured file format such as a markup file (e.g., XML) or an object notation file (e.g., JSON). Continuing with the example where the first resource 202 comprises a list of resources available to the first client 112, such first resource 202 can include a link to the Mth resource 204, which is a “contacts” resource that comprises a list of contacts of the user of the first client 112. When the first client 112 requests the first resource 202, the server 124 generates the data packet based upon the first resource 202, wherein the data packet can be an XML representation of a database that includes a link-relation list comprising a link relation for the Mth resource 204, as follows:
  • <Features>   <link rel=”contacts” href=”/http://example.com/features/contacts”/> </Features>
  • When, as illustrated in FIG. 2, the server 124 maintains multiple versions of the Mth resource 204, the first resource 202 can additionally include a revision attribute in the link-relation for the Mth resource 204 that identifies a most recent version the Mth resource 204 that is available to the first client 112, as follows:
  • <Features>    <link rel=”contacts”    rev=”1”    href=”/http://example.com/features/contacts”/> </Features>

    where “rev” is the revision attribute, and “1” indicates that a first revision of the Mth resource 204 (e.g., a second version the Mth resource 204) is available to the first client 112. The revision attribute can also indicate which versions of a resource are or are not available. For example, the revision attribute can be used to indicate that a second version of a resource is available, but that a third version of the resource is unavailable. Additionally, a lack of a revision attribute in the link-relation can also be considered to be a revision attribute that indicates that the current version of the resource is the only version of the resource (e.g., the first version of the resource).
  • Thus, when the server 124 receives a first version of a resource, there may not be a revision attribute for the resource. When the server 124 receives a revision to the resource, a revision attribute can be generated for the resource, and as additional revisions to the resource are received, the revision attribute can be incremented by one for each revision.
  • The first client 112 further comprises a receiver component 216 that receives the reply transmitted to the first client 112 from the server 124. For example, the receiver component 216 can receive the XML representation of the link-relation comprising the revision attribute described above. The first client 112 can thus locate the identifier of the Mth resource 204. Once the identifier of the Mth resource has been located, the requester component 214 can then transmit a request to retrieve the Mth resource 204 (or data included therein) from the server 124 (e.g., using the “GET” command and the identifier for the Mth resource 204). Effectively, then, the first resource 202 is linked to the Mth resource 204 via the link-relation.
  • Additionally, since the first client 112 has already navigated to the entry endpoint of the application (e.g., by requesting the first resource 202), relative identifiers that are specific to the distributed application can be used to navigate to resources. Thus, the request for the Mth resource 204 generated by the by the requestor component 214 can be as follows:
      • GET contacts
        where “contacts” is the relative identifier of the Mth resource 204.
  • Thus, rather than having to store a contacts list locally, the first client 112 can request content of the Mth resource 204 on the server 124. Using identifiers and methods allows the first client 112 to interact with an endpoint without having to have knowledge as to how the endpoint is stored on the server computing device 106 or the way in which the server 124 implements the requested method for the endpoint.
  • Responsive to receiving the request for the Mth resource 204, the server 124 can transmit a reply to the first client 112. The first client 112 need not specify a version in the request for the Mth resource 204 in order to receive a version of the Mth resource 204 that is compatible with the first client 112. For instance, the first client 112 can be compatible with the first version of the Mth resource 204, and a reply from the server 124 can comprise a data packet for the Kth version 212 of the Mth resource 204. Since, however, the Kth version 212 of the Mth resource 204 comprises the first version 210 of the Mth resource 204, the first client 112 receives a version with which the first client 112 is compatible. In an example, the server 124 can be configured to use a most recent version of the Mth resource to generate the reply. In another example, the requester component 214 can be further configured to include data identifying a version of the client 112 in the request, and the server 124 can transmit a version of the resource known to be compatible with the version of the first client 112 in the reply.
  • Additionally, the requester component 214 can be further configured to request that the reply from the server 124 include a particular version (or versions) of a resource. For example, the first client 112 can be configured to support features that utilize a second version of a resource (e.g., the features are incompatible with the first version of the resource). Thus, the first client 112, in the request, can indicate that the reply is to include a version of the resource that is at least the second version of the resource, and thus is capable of supporting the aforementioned features. In another example, the requester component 214 can be configured to request that the reply include only a particular version of the resource. For example, it may be desirable to minimize a size of the reply transmitted by the server 124, and thus it may be desirable that the reply include the second version of the resource rather than a third version of the resource.
  • In some cases, a particular version or versions of a resource requested by the first client 112 may not be available on the server 124. When this occurs, the server 124 can be configured to include an indication in the reply that the requested version or versions of the resource is not available, and can also be configured to generate a reply that includes a different version of the resource (or data based on the different version of the resource) than the version requested by the first client 112. Thus, when not able to fully comply with a request of the first client 112, the server 124 can be configured to provide available data. In another exemplary embodiment, if the version requested by the first client 112 is not provided by the server 124, the request for the resource fails.
  • In addition to using data in a reply from the server 124 to make additional requests for resources, the first client 112 can be configured to determine information about versions of resources maintained by the server 124 as well as a version of the server 124. To that end, the client 112 further comprises a revision detection component 218 that can determine that a particular resource (or a data packet based on the particular resource) has been received.
  • The revision detection component 218 is configured to determine that a resource has been revised based at least in part upon a comparison between a revision attribute of the resource in a received reply from the server 124 and a revision attribute for a the resource in a previously received reply from the server 124. For instance, in a first communication with the server 124, the first client 112 can receive a reply that includes a data packet corresponding to the first resource 202, wherein the data packet comprises a first revision attribute that indicates that the first version 210 of the Mth resource 204 is available to the first client 112. In a subsequently received reply from the server 124, the first client 112 can receive another data packet corresponding to the first resource 202, wherein the another data packet comprises a second revision attribute that indicates that a second version of the Mth resource 204 is available to the first client 112. By comparing the first revision attribute and the second revision attribute, the revision detection component 218 can determine that the Mth resource has been revised.
  • Such a determination can cause the first client 112 to transmit a notification that the Mth resource 204 has been revised to a developer of the first client 112. Thus, a developer can implement an update for the first client 112 that supports the revision to the Mth resource 204. Furthermore, because the revision attribute pertains to a particular resource (e.g., the Mth resource 204), the developer is informed as to where and how the back-end of the distributed application has been modified without having to consult complicated documentation. Additionally, if the developer has already implemented an update that has yet to be applied to the first client 112, the determination can cause the first client 112 to seek an update or otherwise direct a user to update the first client 112.
  • Updates to the first client 112 and/or the server 124 need not be implemented in a particular sequence or at a particular time, as the RESTlike API can support forward and backward compatibility between clients and servers. Thus, functionality supported by clients and servers in the distributed application can evolve independently without breaking or becoming unusable together. This type of behavior is particularly well-suited in connection with relatively large distributed architectures, where it is not possible to redeploy an entire programming environment every time supported functionality changes.
  • It can be ascertained, however, that not all modifications to the server 124 may comprise a revision of a resource. For example, a modification can include a bug fix or other changes that may have an opaque effect on behavior of the first client 112. To that end, the revision component 218 can also be configured to determine that the server 124 has been revised based at least in part upon a comparison between data in a first reply from the server 124 that indicates that the server 124 is a particular (first) version of the back-end of the distributed application and data in a second reply from the server 124 that indicates that the server 124 is a more recent version of back-end of the distributed application.
  • In another example, it may be desirable for the server 124 to no longer maintain a resource or a particular version of the resource. For instance, the first client 112 can be updated such that a contacts list is no longer used/needed. Thus, the server 124 may be configured to include in the reply an indication that the resource or the particular version of the resource is to be deprecated. Optionally, the indication can include a time when the resource or the particular version of the resource is to be deprecated. Such an indication informs a developer of the first client 112 that the resource or particular version of the resource should be avoided, as it will eventually no longer be maintained by the server 124. The receiver component 216 can receive such indication, and can transmit such indication to the developer.
  • While revisions of resources can be used to support features compatible with different versions of clients, it may also be desirable to make modifications to a resource that would negatively impact compatibility with prior versions of the first client 112. For example, a developer for the distributed application may desire to use a new protocol or implement standards or services that are incompatible with the prior version of first client 112. The RESTlike API supports backward compatibility between the first client 112 and the server 124 in such case by maintaining independent versions of resources.
  • Unlike versions of resources as described above, independently maintained versions of resources are not supersets of previous versions of resources. For example, a first version of the first client 112 can be compatible with the first version 210 of the Mth resource 204, and a second version of the first client 112 can be compatible with the Kth version 212 of the Mth resource 204. In some embodiments, it may be desirable to maintain the first version 210 of the Mth resource 204 independently from the Kth version 212 of the Mth resource 204, to ensure compatibility with the first client 112, regardless of the version thereof.
  • For instance, rather than being a “features” resource that is an entry endpoint to the distributed application, the first resource 202 can be an “application versions” resource and comprise link-relations to different versions of entry endpoints of the application. Thus, a reply transmitted by the server 124 responsive to receiving a request for the first resource 202 can be as follows:
  • <application_versions>   <link rel=“application” href=“http://example.com/v1/application”/>   <link rel=“application2” href=“http://example.com/v2/application”/>   <link rel=“application3” href=“http://example.com/v3/application”/> </ application_versions >

    wherein the first, second and third link-relations correspond to respective versions of entry endpoints the application, as indicated by their respective relation attributes. A client that is compatible with a particular version of the back-end of the distributed application can locate an entry endpoint for the particular version in the reply, and navigate to that entry endpoint.
  • As independently maintained versions of resources are not supersets of previous versions, a revision attribute for an independently maintained version refers to a revision to the version rather than to another version of the resource. For example, a first version of a resource can be subject to revision, such that it becomes a second version of the resource (e.g., version 1.2). Subsequently, the second version of the resource can be revised twice, such that it is a third version of the second version (e.g., version 2.3). Thus, feature-level version control can be maintained for different versions of the server, and the application can maintain backwards-compatibility with versions of the client compatible with different independent versions of the server.
  • Further, as indicated above, forwards compatibility is also supported, where a version of the client 112 may be updated and interact with an older version of the server 124. Thus, the client 112 can continue functioning when communicating with an older server. Conventionally, the server 124 (and other servers on the back-end of the distributed application) are each a most recent version, and may support backward compatibility to support older clients (although the clients are not able to detect resource versions/revisions and/or force certain resource versions/revisions to the server). The features described herein allow for the back-end of the distributed application to include multiple servers of varying versions, wherein such servers interact with multiple clients of varying versions, thereby supporting both forward and backward compatibility.
  • FIGS. 3-11 illustrate exemplary methodologies relating to backwards-compatible feature-level version control of a distributed application through use of a RESTlike API. While the methodologies are shown and described as being a series of acts that are performed in a sequence, it is to be understood and appreciated that the methodologies are not limited by the order of the sequence. For example, some acts can occur in a different order than what is described herein. In addition, an act can occur concurrently with another act. Further, in some instances, not all acts may be required to implement a methodology described herein.
  • Moreover, the acts described herein may be computer-executable instructions that can be implemented by one or more processors and/or stored on a computer-readable medium or media. The computer-executable instructions can include a routine, a sub-routine, programs, a thread of execution, and/or the like. Still further, results of acts of the methodologies can be stored in a computer-readable medium, displayed on a display device, and/or the like.
  • Referring now to FIG. 3, an exemplary methodology 300 that facilitates backwards-compatible feature-level version control of a distributed application through use of a RESTlike API at a client computing device is illustrated. The methodology 300 starts at 302, and at 304, a request is received at a client computing device to execute a client-side instance of a communications application. The communications application uses an API that complies with a REST architecture, wherein the API supports revision of a resource maintained by a server-side instance of the communications application independent of revision to a remainder of the application (e.g., the server-side instance of the application). At 306, the client-side instance of the communications application is executed on the client computing device responsive to receipt of the request. In an example, executing the client-side instance of the application comprises transmitting a request to the server-side instance of the application for a first resource. The methodology 300 completes at 308.
  • Referring now to FIG. 4, an exemplary methodology 400 pertaining to executing a client-side instance (client) of a distributed application is illustrated. The methodology 400 starts at 402, and at 404 the client transmits a request for a first resource to a server-side instance (server) of the communications application. At 406, a reply to the request for the first resource is received from the server. This reply can comprise a version of the resource requested by the client or a data packet comprising data relating to a version of the resource requested by the client. Additionally, the reply can include a data packet that indicates a version of the server, revision attributes, etc.
  • At 408, a version of the server can be identified based at least in part upon the reply received at 406. At 410, the client can infer that a revision has been applied to the server based on a comparison between the version of the server indicated in the reply received at 406 and a version of the server identified in a previously received reply. The methodology 400 completes at 412.
  • Referring now to FIG. 5, another exemplary methodology 500 pertaining to executing a client-side instance (client) of a distributed application is illustrated. The method starts at 502, and at 504 the client transmits a request to a server-side instance (server) of the distributed application for a first resource. At 506, a reply to the request is received by client, wherein the reply is based on a second version of the resource, the reply comprising a first version of the resource that is compatible with the client. The reply is additionally based on a revision that may or may not be compatible with the client.
  • Because at least the first version of the resource is compatible with the client, the client is compatible with the server. At 508, the client can receive an indication that the first version of the first resource is to be deprecated. Such indication can be transmitted to a developer of the client, who can then implement updates to the client that account for the deprecation of the first version of the first resource (the version of the first resource with which the client is compatible). The methodology 500 completes at 510.
  • Referring now to FIG. 6, an exemplary methodology 600 for determining that a resource has been revised is illustrated. The methodology 600 starts at 602, and at 604, a client transmits a request to a server for a first resource. At 606, the client receives a reply to the request, wherein the reply comprises a revision attribute that identifies a second resource, and further identifies a version of the second resource (e.g., a first version). At 608, the client compares the revision attribute with a revision attribute in a previous reply received from the server. At 610, the client determines that the second resource has been revised based on the comparison at 608. Thereafter, a notification can be transmitted to a developer for the client, indicating that the second resource has been revised. The method concludes at 612.
  • Referring now to FIG. 7, yet another exemplary methodology 700 that facilitates retrieval of a resource maintained by a server is illustrated. The methodology 700 starts at 702, and at 704 a client transmits a request to the server for a first resource. At 706, the client receives a reply to the request, wherein the reply comprises a link-relation that identifies a second resource as being available to the client. This link-relation can comprise an identifier of the second resource, and can optionally also comprise a revision attribute of the second resource. The identifier can be a relative identifier, a relation attribute that describes the subject matter of the second resource and/or a global identifier of the second resource. At 708, the client-side instance of the application transmits a request to the server for the second resource. This request can comprise the identifier for the second resource (identified by the client in the link-relation). At 710, the client receives a reply to the request for the second resource. This reply can comprise a version of the second resource or a data packet based upon the second resource, as well as other data. The methodology 700 completes at 712.
  • Referring now to FIG. 8, another exemplary methodology 800 that facilitates retrieving a resource maintained by a server of a distributed communications application is illustrated. The methodology 800 starts at 802, and at 804, a client transmits a request to the server for a first resource. For instance, the request can indicate that a particular version of the resource is desired. At 806, the client receives a reply to the request, wherein the reply includes the version of the first resource that was specified in the request. The methodology 800 completes at 808.
  • Referring now to FIG. 9, an exemplary methodology 900 that can be executed on a server computing device (that executes server-side code for a distributed communications application) is illustrated. The methodology 900 starts at 902, and at 904 the server receives a request from a client for a first resource. For instance, the request can include data that identifies a version of the client. At 906, the server identifies the version of the client based at least in part upon the request. At 908, the server transmits, to the client, a version of the first resource that is compatible with the identified version of the client. The methodology 900 completes at 910.
  • Referring now to FIG. 10, an exemplary methodology 1000 for modifying a resource and providing the modified resource to a client is illustrated. The methodology 1000 starts at 1002, and at 1004, a server receives a first version of a first resource. The server can be configured to maintain the first version of the first resource in computer-readable data storage that is available to the server. At 1006, the server generates a link-relation for the first resource, the link-relation indicating that the first resource is available to the client and further including a revision attribute that identifies the first resource as a first version of the first resource. In an exemplary embodiment, the server can generate the link-relation responsive to receiving a request for the first resource from the client.
  • At 1008, the server receives a second version of the first resource that comprises the first version of the first resource and a revision to the first resource. Alternatively, the server can receive a revision to the first version that may be appended to the first version of the first resource so as to generate the second version of the first resource. At 1010, the server increments the revision attribute of the first resource by one, thereby indicating that the second version of the first resource exists.
  • At 1012, the server receives a request for the first resource from the client. At 1014, responsive to receiving the request at 1012, the server transmits the second version of the first resource to the client. Optionally, the request from the client may identify a particular version of the resource (or a minimum version of the resource). Therefore, the server is configured to reply with a version of the resource that complies with the request, the most recent version of the resource, or a version of the resource that is compatible with the client. The methodology 1000 completes at 1016.
  • Referring now to FIG. 11, a high-level illustration of an exemplary computing device 1100 that can be used in accordance with the systems and methodologies disclosed herein is illustrated. For instance, the computing device 1100 may be used in a system that facilitates backwards-compatible feature-level version control of a distributed application through use of a RESTlike API. The computing device 1100 includes at least one processor 1102 that executes instructions that are stored in a memory 1104. The instructions may be, for instance, instructions for implementing functionality described as being carried out by one or more components discussed above or instructions for implementing one or more of the methods described above. The processor 1102 may access the memory 1104 by way of a system bus 1106. In addition to storing executable instructions, the memory 1104 may also store an instance of an application, a resource, versions of a resource, etc.
  • The computing device 1100 additionally includes a data store 1108 that is accessible by the processor 1102 by way of the system bus 1106. The data store 1108 may include executable instructions, data or metadata pertaining to executing a client or server of a distributed application, resources, API instructions or methods, etc. The computing device 1100 also includes an input interface 1110 that allows external devices to communicate with the computing device 1100. For instance, the input interface 1110 may be used to receive instructions from an external computer device, from a user, etc. The computing device 1100 also includes an output interface 1112 that interfaces the computing device 1100 with one or more external devices. For example, the computing device 1100 may display text, images, etc. by way of the output interface 1112.
  • It is contemplated that the external devices that communicate with the computing device 1100 via the input interface 1110 and the output interface 1112 can be included in an environment that provides substantially any type of user interface with which a user can interact. Examples of user interface types include graphical user interfaces, natural user interfaces, and so forth. For instance, a graphical user interface may accept input from a user employing input device(s) such as a keyboard, mouse, remote control, or the like and provide output on an output device such as a display. Further, a natural user interface may enable a user to interact with the computing device 1100 in a manner free from constraints imposed by input device such as keyboards, mice, remote controls, and the like. Rather, a natural user interface can rely on speech recognition, touch and stylus recognition, gesture recognition both on screen and adjacent to the screen, air gestures, head and eye tracking, voice and speech, vision, touch, gestures, machine intelligence, and so forth.
  • Additionally, while illustrated as a single system, it is to be understood that the computing device 1100 may be a distributed system. Thus, for instance, several devices may be in communication by way of a network connection and may collectively perform tasks described as being performed by the computing device 1100.
  • Various functions described herein can be implemented in hardware, software, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer-readable storage media. A computer-readable storage media can be any available storage media that can be accessed by a computer. By way of example, and not limitation, such computer-readable storage 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, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc (BD), where disks usually reproduce data magnetically and discs usually reproduce data optically with lasers. Further, a propagated signal is not included within the scope of computer-readable storage media. Computer-readable media also includes communication media including any medium that facilitates transfer of a computer program from one place to another. A connection, for instance, can be a communication medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio and microwave are included in the definition of communication medium. Combinations of the above should also be included within the scope of computer-readable media.
  • Alternatively, or in addition, the functionally described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc. The processor module and/or a combination of the processor module and associated memory described herein is intended to encompass any of such hardware logic components.
  • What has been described above includes examples of one or more embodiments. It is, of course, not possible to describe every conceivable modification and alteration of the above devices or methodologies for purposes of describing the aforementioned aspects, but one of ordinary skill in the art can recognize that many further modifications and permutations of various aspects are possible. Accordingly, the described aspects are intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the details description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.

Claims (20)

What is claimed is:
1. A computing device comprising:
a processor module; and
a memory that comprises a client-side instance of a distributed application executed by the processor module, the distributed application supporting communication between the client-side instance of the application and a server-side instance of the application through use of an application programming interface (API) that complies with a representational state transfer (REST) architecture, the API supporting revision of a resource maintained by the server-side instance of the application independent of other revisions to the distributed application.
2. The computing device of claim 1, the client-side instance of the distributed application comprising:
a requester component that transmits a request to the server-side instance of the application for a first resource maintained by the server-side instance of the distributed application, the request comprising at least one of an identifier of the first resource or a relation attribute that describes content of the first resource; and
a receiver component configured to receive a reply to the request.
3. The computing device of claim 2, the client-side instance of the distributed application being compatible with a first version of the first resource, the reply comprising a second version of the first resource, the second version of the first resource comprising the first version of the first resource and a revision to the first version of the first resource.
4. The computing device of claim 2, the reply comprising a revision attribute for a second resource that identifies the second resource as being a Kth version of the second resource, the client-side instance of the application further comprising a revision detection component that determines that the second resource has been revised based at least in part upon a comparison between the revision attribute for the second resource and a revision attribute for a prior version of the second resource.
5. The computing device of claim 2, the request comprising data that identifies a version of the client-side instance of the distributed application.
6. The computing device of claim 2, the reply comprising data that identifies a version of the server-side instance of the distributed application, the client-side instance of the distributed application further comprising a revision detection component that infers a revision to the server-side instance of the application based at least in part upon a comparison between the data that identifies the version of the server-side instance of the distributed application and content of a previously received reply from the server-side instance of the distributed application.
7. The computing device of claim 2, the reply comprising an indication that the first resource is to be deprecated.
8. The computing device of claim 2, the reply comprising a link-relation comprised by the first resource, the link-relation identifying that a second resource is available to the client-side instance of the application, the link relation comprising:
an identifier of the second resource;
a relation attribute that describes a subject matter of the second resource; and
a revision attribute that identifies a version of the second resource.
9. The computing device of claim 8, the requester component further configured to transmit a request to the server-side instance of the distributed application for the second resource, the request comprising at least one of the identifier of the second resource or the relation attribute that describes the subject matter the second resource.
10. The computing device of claim 8, the reply comprising a second link-relation comprised by the first resource, the second link-relation identifying a third resource that is available to the client-side instance of the application, the third resource being an independent version of the second resource that fails to comprise the second resource.
11. The computing device of claim 1, the distributed application being a unified communications application.
12. A method executed by a processor module of a computing device, the method comprising:
receiving a command to execute a client-side instance of a distributed application that supports bi-directional communication between the client-side instance and a server-side instance of the distributed application, an application programming interface (API) supporting the bi-directional communication, the API complying with a representational state transfer (REST) architecture and supporting revision of a resource maintained by the server-side instance of the distributed application independent of revision to a remainder of the distributed application; and
executing the client-side instance of the distributed application responsive to receiving the command, wherein executing the client-side instance of the distributed application comprises transmitting a request for a first resource to the server-side instance of the distributed application.
13. The method of claim 12, wherein the request comprises at least one of an identifier of the first resource or a relation attribute that describes a subject matter the first resource, and the method further comprising:
receiving a reply to the request from the server-side instance of the distributed application.
14. The method of claim 13, wherein the reply further comprises a first version of the first resource, the first version of the first resource comprising:
a second version of the resource that is compatible with the client-side instance of the distributed application; and
a revision to the second resource.
15. The method of claim 13, wherein the reply further comprises a revision attribute for a second resource, the revision attribute identifying a version of the second resource, the method further comprising:
determining that the second resource has been revised based at least in part upon a comparison between the reply and a previously received reply pertaining to the first resource.
16. The method of claim 13; wherein the reply further comprises a link-relation comprised by the first resource, the link-relation identifying a second resource as being available to the client-side instance of the distributed application, the link-relation comprising:
an identifier of the second resource;
a relation attribute that describes a subject matter of the second resource; and
a revision attribute that identifies a version of the second resource.
17. The method of claim 16, wherein executing the client-side instance of the distributed application further comprises transmitting a request to the server-side instance of the application for the second resource, the request comprising at least one of an identifier of the second resource or the relation attribute that describes the subject matter of the second resource.
18. The method of claim 13, wherein transmitting of the request further comprises requesting a particular version of the first resource, and wherein executing the client-side instance of the distributed application further comprises receiving a reply to the request, the reply comprising the particular version of the first resource.
19. The method of claim 13, wherein executing the client-side instance of the distributed application further comprises receiving a reply to the request, the reply comprising an indication that at least one version of the first resource is to be deprecated.
20. A computer readable storage medium comprising instructions that, when executed by a processor, cause the processor to perform acts comprising:
executing a client-side instance of a unified communications (UC) application, the UC application supporting multiple modes of communication between the client-side instance of the UC application and a server-side instance of the UC application by way of an application programming interface (API), the API complying with a representational state transfer (REST) architecture and supporting revision of a resource maintained by the server-side instance of the UC application independent of revision to a remainder of the UC application, wherein executing the client-side instance of the UC application comprises:
transmitting a request to the server-side instance of the UC application for a first resource, the request comprising at least one of an identifier of the first resource or a relation attribute that describes content of the first resource; and
receiving a reply to the request, the reply comprising a version of the first resource selected by the server from amongst a plurality of possible versions of the first resource that is compatible with the client-side instance of the UC application.
US13/927,112 2013-02-28 2013-06-26 Backwards-compatible feature-level version control of an application using a restlike api Abandoned US20140244708A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US201361771073P true 2013-02-28 2013-02-28
US13/927,112 US20140244708A1 (en) 2013-02-28 2013-06-26 Backwards-compatible feature-level version control of an application using a restlike api

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US13/927,112 US20140244708A1 (en) 2013-02-28 2013-06-26 Backwards-compatible feature-level version control of an application using a restlike api
EP14712393.9A EP2949108B1 (en) 2013-02-28 2014-02-26 Backwards-compatible feature-level version control of an application using a restlike api
CN201480011155.3A CN105027535A (en) 2013-02-28 2014-02-26 Backwards-compatible feature-level version control of an application using a restlike api
PCT/US2014/018460 WO2014134082A1 (en) 2013-02-28 2014-02-26 Backwards-compatible feature-level version control of an application using a restlike api

Publications (1)

Publication Number Publication Date
US20140244708A1 true US20140244708A1 (en) 2014-08-28

Family

ID=51389315

Family Applications (5)

Application Number Title Priority Date Filing Date
US13/925,854 Active US9954843B2 (en) 2013-02-28 2013-06-25 Web ticket based upon a symmetric key usable for user authentication
US13/925,827 Active 2035-06-25 US9838375B2 (en) 2013-02-28 2013-06-25 RESTlike API that supports a resilient and scalable distributed application
US13/927,112 Abandoned US20140244708A1 (en) 2013-02-28 2013-06-26 Backwards-compatible feature-level version control of an application using a restlike api
US13/927,116 Abandoned US20140244721A1 (en) 2013-02-28 2013-06-26 Real-time communications using a restlike api
US15/947,705 Active US10356078B2 (en) 2013-02-28 2018-04-06 Web ticket based upon a symmetric key usable for user authentication

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US13/925,854 Active US9954843B2 (en) 2013-02-28 2013-06-25 Web ticket based upon a symmetric key usable for user authentication
US13/925,827 Active 2035-06-25 US9838375B2 (en) 2013-02-28 2013-06-25 RESTlike API that supports a resilient and scalable distributed application

Family Applications After (2)

Application Number Title Priority Date Filing Date
US13/927,116 Abandoned US20140244721A1 (en) 2013-02-28 2013-06-26 Real-time communications using a restlike api
US15/947,705 Active US10356078B2 (en) 2013-02-28 2018-04-06 Web ticket based upon a symmetric key usable for user authentication

Country Status (5)

Country Link
US (5) US9954843B2 (en)
EP (4) EP2949108B1 (en)
CN (4) CN105900391A (en)
ES (1) ES2613831T3 (en)
WO (4) WO2014134085A1 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140282469A1 (en) * 2013-03-15 2014-09-18 Microsoft Corporation Mechanism for safe and reversible rolling upgrades
US20140351347A1 (en) * 2013-05-21 2014-11-27 International Business Machines Corporation Generating instant messaging contacts for customer relationship management systems
US20150074256A1 (en) * 2013-09-06 2015-03-12 Futurewei Technologies Inc. System and method for fast compatibility verification of rest api based on rest chart
US20160360011A1 (en) * 2015-06-05 2016-12-08 Canon Kabushiki Kaisha System, server system, method, and storage medium
US9854029B1 (en) * 2014-11-04 2017-12-26 Amazon Technologies, Inc. Systems for determining improper assignments in statistical hypothesis testing
US10203953B2 (en) 2017-02-24 2019-02-12 Microsoft Technology Licensing, Llc Identification of duplicate function implementations
US10298656B2 (en) * 2016-06-08 2019-05-21 Western Digital Technologies, Inc. Extending representational state transfer application program interface (REST API) functionality
US10338910B2 (en) 2015-01-05 2019-07-02 Entit Software Llc Multi-tenant upgrading
US10355882B2 (en) * 2014-08-05 2019-07-16 Damaka, Inc. System and method for providing unified communications and collaboration (UCC) connectivity between incompatible systems
US10643147B2 (en) 2016-05-31 2020-05-05 International Business Machines Corporation Coordinated version control system, method, and recording medium for parameter sensitive applications

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8769031B1 (en) * 2013-04-15 2014-07-01 Upfront Media Group, Inc. System and method for implementing a subscription-based social media platform
US10567184B2 (en) 2016-02-19 2020-02-18 Vertigo Media, Inc. System and method for group stream broadcasting with stateless queuing feature
US10044799B2 (en) 2013-05-28 2018-08-07 International Business Machines Corporation Implementing synchronization of state information betweeen instances of an application as well as between different applications in an efficient, scalable manner
US9854035B2 (en) 2013-05-28 2017-12-26 International Business Machines Corporation Maintaining state synchronization of an application between computing devices as well as maintaining state synchronization of common information between different applications without requiring periodic synchronization
CN104243273A (en) * 2013-06-09 2014-12-24 阿里巴巴集团控股有限公司 Method and device for displaying information on instant messaging client and information display system
WO2014205645A1 (en) * 2013-06-25 2014-12-31 Nokia Corporation A method and apparatus for anonymous and trustworthy authentication in pervasive social networking
CN105493438A (en) * 2013-07-01 2016-04-13 诺基亚技术有限公司 A method and apparatus for anonymous authentication on trust in social networking
US9736130B1 (en) * 2013-07-05 2017-08-15 Sonus Networks, Inc. Communications methods and apparatus related to web initiated sessions
US20150113121A1 (en) * 2013-10-18 2015-04-23 Telefonaktiebolaget L M Ericsson (Publ) Generation at runtime of definable events in an event based monitoring system
JP6287335B2 (en) * 2014-02-28 2018-03-07 株式会社リコー Terminal device, information processing system, information transmission method, and program
US10223407B2 (en) * 2014-10-31 2019-03-05 Cisco Technology, Inc. Asynchronous processing time metrics
US10057365B1 (en) * 2015-06-24 2018-08-21 Amazon Technologies, Inc. Asynchronous provision of resource status data
US10298642B2 (en) * 2016-02-17 2019-05-21 Quickbiz Holdings Limited, Apia User interface content state synchronization across devices
CN105704562B (en) * 2016-03-29 2020-01-03 Tcl集团股份有限公司 Multi-version compatible method and device for network television cloud service platform
CN106897053B (en) * 2016-07-08 2020-06-26 阿里巴巴集团控股有限公司 Code publishing method and device
US10484302B2 (en) 2016-08-27 2019-11-19 Nicira, Inc. Managed forwarding element executing in public cloud data compute node with different internal and external network addresses
US10333959B2 (en) 2016-08-31 2019-06-25 Nicira, Inc. Use of public cloud inventory tags to configure data compute node for logical network
US20180088960A1 (en) * 2016-09-23 2018-03-29 International Business Machines Corporation Providing highly available and scalable access to a restricted access service through a restful interface
CN106778380B (en) * 2016-11-28 2019-11-19 昆山国显光电有限公司 The lighting method and system of screen
US10491698B2 (en) 2016-12-08 2019-11-26 International Business Machines Corporation Dynamic distribution of persistent data
US10574724B2 (en) * 2017-01-06 2020-02-25 Western Digital Technologies, Inc. Automatic discovery of management nodes and generation of CLI using HA module
US10462265B2 (en) * 2017-02-17 2019-10-29 Plex, Inc. On-demand startup of offline servers and connection routing
CN106790285B (en) * 2017-02-27 2019-09-06 杭州迪普科技股份有限公司 A kind of Session state reuse method and device
CN107277140A (en) * 2017-06-21 2017-10-20 山东浪潮通软信息科技有限公司 A kind of distribution method of application programming interfaces, route middleware and operation system
US10673715B2 (en) * 2017-07-20 2020-06-02 Servicenow, Inc. Splitting network discovery payloads based on degree of relationships between nodes
US10491516B2 (en) 2017-08-24 2019-11-26 Nicira, Inc. Packet communication between logical networks and public cloud service providers native networks using a single network interface and a single routing table
US10567482B2 (en) 2017-08-24 2020-02-18 Nicira, Inc. Accessing endpoints in logical networks and public cloud service providers native networks using a single network interface and a single routing table
US10601705B2 (en) 2017-12-04 2020-03-24 Nicira, Inc. Failover of centralized routers in public cloud logical networks
CN110166962A (en) * 2018-02-14 2019-08-23 华为技术有限公司 A kind of regulation management method and apparatus
US10673855B2 (en) * 2018-04-10 2020-06-02 Sap Se Consolidated identity management system provisioning to manage access across landscapes
US10642804B2 (en) 2018-06-28 2020-05-05 Bank Of America Corporation Dynamic network database integration system
US10491466B1 (en) 2018-08-24 2019-11-26 Vmware, Inc. Intelligent use of peering in public cloud
US10819586B2 (en) * 2018-10-17 2020-10-27 Servicenow, Inc. Functional discovery and mapping of serverless resources
US10769586B2 (en) 2018-11-29 2020-09-08 Red Hat, Inc. Implementation of rolling key to identify systems inventories

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050125461A1 (en) * 2003-12-08 2005-06-09 International Business Machines Corporation Version control of metadata
US20060075079A1 (en) * 2004-10-06 2006-04-06 Digipede Technologies, Llc Distributed computing system installation
US20070124797A1 (en) * 2003-07-25 2007-05-31 Rajiv Gupta Policy based service management
US20080147834A1 (en) * 2006-12-19 2008-06-19 Quinn William M System and method for achieving highly scalable real-time collaboration applications using http
US20100217636A1 (en) * 2009-02-26 2010-08-26 International Business Machines Corporation Management of a service oriented architecture shared service
US20100235509A1 (en) * 2007-06-01 2010-09-16 Alibaba Group Holding Limited Method, Equipment and System for Resource Acquisition
US8370467B1 (en) * 2011-10-07 2013-02-05 Google Inc. Method for seamlessly providing incremental application updates to users while serving continuous live traffic

Family Cites Families (84)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9900305B2 (en) * 1998-01-12 2018-02-20 Soverain Ip, Llc Internet server access control and monitoring systems
US6370571B1 (en) * 1997-03-05 2002-04-09 At Home Corporation System and method for delivering high-performance online multimedia services
US6065117A (en) 1997-07-16 2000-05-16 International Business Machines Corporation Systems, methods and computer program products for sharing state information between a stateless server and a stateful client
US6263432B1 (en) * 1997-10-06 2001-07-17 Ncr Corporation Electronic ticketing, authentication and/or authorization security system for internet applications
US6985953B1 (en) * 1998-11-30 2006-01-10 George Mason University System and apparatus for storage and transfer of secure data on web
US20020078144A1 (en) * 1999-04-21 2002-06-20 Lamkin Allan B. Presentation of media content from multiple media
US6421768B1 (en) * 1999-05-04 2002-07-16 First Data Corporation Method and system for authentication and single sign on using cryptographically assured cookies in a distributed computer environment
US7188181B1 (en) * 1999-06-30 2007-03-06 Sun Microsystems, Inc. Universal session sharing
US6405216B1 (en) 1999-09-17 2002-06-11 International Business Machines Corporation Internet-based application program interface (API) documentation interface
US7137006B1 (en) * 1999-09-24 2006-11-14 Citicorp Development Center, Inc. Method and system for single sign-on user access to multiple web servers
US6678733B1 (en) * 1999-10-26 2004-01-13 At Home Corporation Method and system for authorizing and authenticating users
WO2001055819A1 (en) * 2000-01-27 2001-08-02 Hummingbird Ltd. A method and system for implementing a common user logon to multiple applications
US20020138728A1 (en) * 2000-03-07 2002-09-26 Alex Parfenov Method and system for unified login and authentication
US6950522B1 (en) * 2000-06-15 2005-09-27 Microsoft Corporation Encryption key updating for multiple site automated login
US7194764B2 (en) * 2000-07-10 2007-03-20 Oracle International Corporation User authentication
US20030115452A1 (en) * 2000-12-19 2003-06-19 Ravi Sandhu One time password entry to access multiple network sites
US8488766B2 (en) * 2001-02-27 2013-07-16 Verizon Data Services Llc Methods and systems for multiuser selective notification
US7218739B2 (en) * 2001-03-09 2007-05-15 Microsoft Corporation Multiple user authentication for online console-based gaming
US7421083B2 (en) * 2001-04-05 2008-09-02 General Instrument Corporation System for seamlessly updating service keys with automatic recovery
US20030037237A1 (en) * 2001-04-09 2003-02-20 Jean-Paul Abgrall Systems and methods for computer device authentication
US20020150253A1 (en) * 2001-04-12 2002-10-17 Brezak John E. Methods and arrangements for protecting information in forwarded authentication messages
US6986047B2 (en) * 2001-05-10 2006-01-10 International Business Machines Corporation Method and apparatus for serving content from a semi-trusted server
US7010600B1 (en) * 2001-06-29 2006-03-07 Cisco Technology, Inc. Method and apparatus for managing network resources for externally authenticated users
US7562387B2 (en) * 2001-09-07 2009-07-14 International Business Machines Corporation Method and apparatus for selective disabling of tracking of click stream data
US7818792B2 (en) * 2002-02-04 2010-10-19 General Instrument Corporation Method and system for providing third party authentication of authorization
US7523490B2 (en) * 2002-05-15 2009-04-21 Microsoft Corporation Session key security protocol
US7305629B2 (en) 2002-09-26 2007-12-04 International Business Machines Corporation Consolidation of computer documentation
US7360096B2 (en) * 2002-11-20 2008-04-15 Microsoft Corporation Securely processing client credentials used for Web-based access to resources
US8069435B1 (en) * 2003-08-18 2011-11-29 Oracle America, Inc. System and method for integration of web services
US20060174110A1 (en) * 2005-01-31 2006-08-03 Microsoft Corporation Symmetric key optimizations
US20060277596A1 (en) * 2005-06-06 2006-12-07 Calvert Peter S Method and system for multi-instance session support in a load-balanced environment
US7580719B2 (en) 2005-09-21 2009-08-25 U Owe Me, Inc SMS+: short message service plus context support for social obligations
US20070073625A1 (en) * 2005-09-27 2007-03-29 Shelton Robert H System and method of licensing intellectual property assets
GB0523871D0 (en) * 2005-11-24 2006-01-04 Ibm A system for updating security data
CN101326515A (en) * 2005-12-09 2008-12-17 微软公司 Metadata driven deployment of applications
US7716180B2 (en) 2005-12-29 2010-05-11 Amazon Technologies, Inc. Distributed storage system with web services client interface
US8589574B1 (en) * 2005-12-29 2013-11-19 Amazon Technologies, Inc. Dynamic application instance discovery and state management within a distributed system
US8225385B2 (en) * 2006-03-23 2012-07-17 Microsoft Corporation Multiple security token transactions
US8201217B1 (en) * 2006-10-03 2012-06-12 Stamps.Com Inc. Systems and methods for single sign-in for multiple accounts
US7765195B2 (en) * 2006-11-07 2010-07-27 Microsoft Corporation Trimmed and merged search result sets in a versioned data environment
US20080208959A1 (en) * 2007-02-22 2008-08-28 St John Sean Hanging request system and method for client/server communication
US9813382B2 (en) * 2007-03-07 2017-11-07 Adobe Systems Incorporated Cryptographic binding of multiple secured connections
US8274968B2 (en) 2007-07-20 2012-09-25 Cisco Technology, Inc. Restriction of communication in VoIP address discovery system
US8332922B2 (en) * 2007-08-31 2012-12-11 Microsoft Corporation Transferable restricted security tokens
US20090177735A1 (en) 2007-12-21 2009-07-09 Nortel Networks Limited Unified communications systems and methods
US8417593B2 (en) * 2008-02-28 2013-04-09 Sap Ag System and computer-readable medium for managing consistent interfaces for business objects across heterogeneous systems
US8621598B2 (en) * 2008-03-12 2013-12-31 Intuit Inc. Method and apparatus for securely invoking a rest API
US8306021B2 (en) * 2008-04-02 2012-11-06 Twilio, Inc. System and method for processing telephony sessions
US8943560B2 (en) 2008-05-28 2015-01-27 Microsoft Corporation Techniques to provision and manage a digital telephone to authenticate with a network
US8527631B1 (en) * 2008-06-26 2013-09-03 Trend Micro, Inc. Web site reputation service using proxy auto-configuration
US8438622B2 (en) * 2008-07-10 2013-05-07 Honesty Online, Llc Methods and apparatus for authorizing access to data
US8095972B1 (en) * 2008-10-06 2012-01-10 Southern Company Services, Inc. Secure authentication for web-based applications
CN102246489B (en) * 2008-10-08 2014-05-28 思杰系统有限公司 Systems and methods for connection management for asynchronous messaging over http
US8780718B2 (en) 2008-11-25 2014-07-15 Citrix Systems, Inc. Systems and methods for maintaining persistence by a backup virtual server
US8260926B2 (en) 2008-11-25 2012-09-04 Citrix Systems, Inc. Systems and methods for GSLB site persistence
US8005895B2 (en) * 2009-02-27 2011-08-23 Microsoft Corporation Distributed routing of conferences using conference identifier
US8527774B2 (en) * 2009-05-28 2013-09-03 Kaazing Corporation System and methods for providing stateless security management for web applications using non-HTTP communications protocols
US9531695B2 (en) 2009-06-12 2016-12-27 Microsoft Technology Licensing, Llc Access control to secured application features using client trust levels
US8195626B1 (en) * 2009-06-18 2012-06-05 Amazon Technologies, Inc. Compressing token-based files for transfer and reconstruction
US8856869B1 (en) * 2009-06-22 2014-10-07 NexWavSec Software Inc. Enforcement of same origin policy for sensitive data
WO2011027457A1 (en) * 2009-09-04 2011-03-10 富士通株式会社 Transmission system, transmission device, and update data acquisition method
US20110154222A1 (en) 2009-12-18 2011-06-23 Microsoft Corporation Extensible mechanism for conveying feature capabilities in conversation systems
US8572710B2 (en) * 2010-03-18 2013-10-29 Microsoft Corporation Pluggable token provider model to implement authentication across multiple web services
US9247008B2 (en) 2010-03-18 2016-01-26 Microsoft Corporation Unified web service discovery
US8315165B2 (en) * 2010-06-07 2012-11-20 Microsoft Corporation Survivable and resilient real time communication architecture
US20110307541A1 (en) * 2010-06-10 2011-12-15 Microsoft Corporation Server load balancing and draining in enhanced communication systems
US9397861B1 (en) * 2010-07-16 2016-07-19 Shoretel, Inc. Unified communication
CN102143200B (en) * 2010-10-20 2013-09-11 华为技术有限公司 Public message header carrying method and public message header carrying device for transferring SOAP API into REST API
US9529578B2 (en) * 2010-10-20 2016-12-27 Hewlett Packard Enterprise Development Lp Automated service version upgrading
WO2012098453A1 (en) * 2011-01-17 2012-07-26 Telefonactiebolaget Lm Ericsson (Publ) Http notification gateway
US8549533B2 (en) * 2011-03-18 2013-10-01 Telefonaktiebolaget L M Ericsson (Publ) Ranking service units to provide and protect highly available services using N+M redundancy models
US9489658B2 (en) * 2011-03-25 2016-11-08 Telcentris, Inc. Universal communication system
US20120284804A1 (en) * 2011-05-02 2012-11-08 Authentec, Inc. System and method for protecting digital contents with digital rights management (drm)
US8805984B2 (en) * 2011-07-14 2014-08-12 Red Hat, Inc. Multi-operational transactional access of in-memory data grids in a client-server environment
US8958783B2 (en) 2011-07-26 2015-02-17 Mitel Networks Corporation System and method for short-range electronic communication
KR101314424B1 (en) * 2011-08-24 2013-11-13 주식회사 팬택 Terminal, ims server and method for transmitting/receiving presence information
US9094212B2 (en) * 2011-10-04 2015-07-28 Microsoft Technology Licensing, Llc Multi-server authentication token data exchange
WO2013054196A2 (en) * 2011-10-14 2013-04-18 Open Text S.A. System and method for secure content sharing and synchronization
US8689243B2 (en) * 2011-11-04 2014-04-01 Microsoft Corporation Web service API for unified contact store
US20130191882A1 (en) * 2012-01-19 2013-07-25 Sap Ag Access control of remote communication interfaces based on system-specific keys
US9100497B2 (en) * 2012-04-05 2015-08-04 Blackberry Limited Method, system and apparatus for managing persona-based notifications at a communication device
US9344458B2 (en) * 2012-07-16 2016-05-17 eZuce, Inc. Providing unified communications services
US8983987B2 (en) * 2012-07-25 2015-03-17 Cisco Technology, Inc. System and method for a service metering framework in a network environment
US9491266B2 (en) * 2012-12-03 2016-11-08 Sap Se Representational state transfer communications via remote function calls

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070124797A1 (en) * 2003-07-25 2007-05-31 Rajiv Gupta Policy based service management
US20050125461A1 (en) * 2003-12-08 2005-06-09 International Business Machines Corporation Version control of metadata
US20060075079A1 (en) * 2004-10-06 2006-04-06 Digipede Technologies, Llc Distributed computing system installation
US20080147834A1 (en) * 2006-12-19 2008-06-19 Quinn William M System and method for achieving highly scalable real-time collaboration applications using http
US20100235509A1 (en) * 2007-06-01 2010-09-16 Alibaba Group Holding Limited Method, Equipment and System for Resource Acquisition
US20100217636A1 (en) * 2009-02-26 2010-08-26 International Business Machines Corporation Management of a service oriented architecture shared service
US8370467B1 (en) * 2011-10-07 2013-02-05 Google Inc. Method for seamlessly providing incremental application updates to users while serving continuous live traffic

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Restore An Older Version Of A Document", 18 March 2011, googledocstips.com (4 pages) *

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140282469A1 (en) * 2013-03-15 2014-09-18 Microsoft Corporation Mechanism for safe and reversible rolling upgrades
US9710250B2 (en) * 2013-03-15 2017-07-18 Microsoft Technology Licensing, Llc Mechanism for safe and reversible rolling upgrades
US9621494B2 (en) 2013-05-21 2017-04-11 International Business Machines Corporation Generating instant messaging contacts for customer relationship management systems
US20140351347A1 (en) * 2013-05-21 2014-11-27 International Business Machines Corporation Generating instant messaging contacts for customer relationship management systems
US9762514B2 (en) * 2013-05-21 2017-09-12 International Business Machines Corporation Generating instant messaging contacts for customer relationship management systems
US9654334B2 (en) * 2013-09-06 2017-05-16 Futurewei Technologies, Inc. System and method for fast compatibility verification of REST API based on REST Chart
US20150074256A1 (en) * 2013-09-06 2015-03-12 Futurewei Technologies Inc. System and method for fast compatibility verification of rest api based on rest chart
US10355882B2 (en) * 2014-08-05 2019-07-16 Damaka, Inc. System and method for providing unified communications and collaboration (UCC) connectivity between incompatible systems
US9854029B1 (en) * 2014-11-04 2017-12-26 Amazon Technologies, Inc. Systems for determining improper assignments in statistical hypothesis testing
US10338910B2 (en) 2015-01-05 2019-07-02 Entit Software Llc Multi-tenant upgrading
US20160360011A1 (en) * 2015-06-05 2016-12-08 Canon Kabushiki Kaisha System, server system, method, and storage medium
US10643147B2 (en) 2016-05-31 2020-05-05 International Business Machines Corporation Coordinated version control system, method, and recording medium for parameter sensitive applications
US10657459B2 (en) 2016-05-31 2020-05-19 International Business Machines Corporation Coordinated version control system, method, and recording medium for parameter sensitive applications
US10298656B2 (en) * 2016-06-08 2019-05-21 Western Digital Technologies, Inc. Extending representational state transfer application program interface (REST API) functionality
US10203953B2 (en) 2017-02-24 2019-02-12 Microsoft Technology Licensing, Llc Identification of duplicate function implementations

Also Published As

Publication number Publication date
CN105144659A (en) 2015-12-09
EP2949102A1 (en) 2015-12-02
EP2949102B1 (en) 2019-03-27
EP2949108A1 (en) 2015-12-02
EP2962440B1 (en) 2017-01-04
WO2014134083A1 (en) 2014-09-04
US9954843B2 (en) 2018-04-24
WO2014134082A1 (en) 2014-09-04
CN105027535A (en) 2015-11-04
US10356078B2 (en) 2019-07-16
WO2014134085A1 (en) 2014-09-04
ES2613831T3 (en) 2017-05-26
EP2949108B1 (en) 2017-04-12
EP2962445A1 (en) 2016-01-06
EP2962440A1 (en) 2016-01-06
WO2014134081A1 (en) 2014-09-04
US20140245420A1 (en) 2014-08-28
US20140244818A1 (en) 2014-08-28
US20140244721A1 (en) 2014-08-28
US20180227291A1 (en) 2018-08-09
CN105900391A (en) 2016-08-24
US9838375B2 (en) 2017-12-05
CN105210348A (en) 2015-12-30

Similar Documents

Publication Publication Date Title
US9851953B2 (en) Cloud based editor for generation of interpreted artifacts for mobile runtime
US9332063B2 (en) Versatile application configuration for deployable computing environments
KR102111080B1 (en) Distribution of multiple application versions
US10055113B2 (en) System and method for modifying user interface elements
US10762277B2 (en) Optimization schemes for controlling user interfaces through gesture or touch
US9904537B2 (en) Providing a hybrid application
US9330141B2 (en) Federated query engine for federation of data queries across structure and unstructured data
US9418074B2 (en) System and method for updating a search results page in response to a user map interaction
JP6698646B2 (en) JSON style sheet language conversion
CN102521230B (en) For the result type that data with good conditionsi show
US20160188549A1 (en) Systems and methods for managing loading priority or sequencing of fragments of a web object
US10205674B2 (en) Incorporating web applications into web pages at the network level
US8438312B2 (en) Dynamically rehosting web content
US10303679B2 (en) Ensuring snapshot monotonicity in asynchronous data replication
AU2011279270B2 (en) Sharing and deconflicting data changes in a multimaster database system
US8332520B2 (en) Web server for managing session and method thereof
JP4824110B2 (en) Computer-implemented method, computer program, and data processing system for inheriting page layout for a page
US8838808B2 (en) Asynchronous communication in web applications
US8407290B2 (en) Dynamic data sharing using a collaboration-enabled web browser
US10243889B2 (en) Keyword based automatic reply generation in a messaging application
US9026935B1 (en) Application user interface with an interactive overlay
US20140244818A1 (en) Restlike api that supports a resilient and scalable distributed application
US7954052B2 (en) Method for processing a web page for display in a wiki environment
AU2012271774B2 (en) Automated user interface object transformation and code generation
US9026583B2 (en) Method and apparatus for polymorphic serialization

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT CORPORATION, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TAINE, STEPHANE;RAO, DEEPAK;YOUNIS, SHAHZAIB;SIGNING DATES FROM 20130621 TO 20130624;REEL/FRAME:030685/0274

AS Assignment

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034747/0417

Effective date: 20141014

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:039025/0454

Effective date: 20141014

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION