Using multivariate HTTP requests to identify HTTP resources

Abstract

A technique for identifying one or more HTTP resources using a multivariate HTTP request is disclosed. A server receives an HTTP request to perform an operation, extracts field names and field values ​​specified in the HTTP request, and defines a query based on the field names and field values. The server executes the query to identify any resources having field values ​​for fields having the field names, and identifies the resources in a query result set corresponding to the query. The server then performs the operation on the resources identified in the query result set.

Description

[0001] Rights Declaration

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 579,694, filed October 31, 2017, which is incorporated herein by reference.

[0003] Applicant hereby retracts any assertions of claim scope made in the parent application or its prosecution history, and puts the USPTO on notice that the claims in this application may be broader than any claims in the parent application. Technical Field

[0004] The present disclosure relates to HTTP protocol requests. In particular, the present disclosure relates to identifying HTTP resources using multivariate HTTP requests. Background Art

[0005] A distributed computing system includes computing servers that can be accessed via a public Internet Protocol (IP) network (such as the Internet) or a private local area network (LAN) by referencing a Uniform Resource Locator (URL) or Uniform Resource Identifier (URI) that identifies the server. Distributed computing systems typically use a Hypertext Transfer Protocol (HTTP) interface to communicate with the computing servers. The HTTP protocol includes non-secure protocols (e.g., "http") and secure protocols (e.g., "https").

[0006] Requests to web services are typically formatted according to the HTTP protocol. Such requests to web services may be referred to herein as HTTP requests. HTTP requests typically use a Uniform Resource Identifier (URI) with a clear directory structure to identify the target resource corresponding to the web service. HTTP requests may include various HTTP methods for processing resources. Examples of HTTP methods may include, but are not limited to, GET, POST, PUT, and DELETE. Some HTTP methods are used for stateless transactions, which do not store the client context on the server between requests. In a stateless client / server transaction, the client maintains the session state.

[0007] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by their inclusion in this section. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In the figures of the accompanying drawings, embodiments are illustrated by way of example and not limitation. It should be noted that references to "an" or "an" embodiment in this disclosure do not necessarily refer to the same embodiment, and references to "an" or "an" embodiment mean at least one. In the drawings:

[0009] Figure 1 is a block diagram illustrating a distributed computing system for identifying HTTP resources using multivariate HTTP requests according to one or more embodiments;

[0010] Figure 2A 、 2B and 2C is a diagram illustrating formatting of an HTTP request for identifying an HTTP resource according to one or more embodiments;

[0011] Figure 3 is a flow chart illustrating processing of a multivariate HTTP request for identifying an HTTP resource according to one or more embodiments;

[0012] Figure 4 is a block diagram illustrating a distributed computing system for identifying client assets in a server that correspond to assets in a client using multivariate HTTP requests according to one or more embodiments; and

[0013] Figure 5 is a block diagram illustrating a computer system according to one or more embodiments. DETAILED DESCRIPTION

[0014] In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding. One or more embodiments may be practiced without these specific details. Features described in one embodiment may be combined with features described in different embodiments. In some examples, well-known structures and devices are described with reference to block diagrams to avoid unnecessarily obscuring the present invention.

[0015] 1. General Overview

[0016] In various embodiments, a client computing system specifies a tag / value pair in an HTTP request to a server computing system. The tag may correspond to a field name. The tag / value pair may identify one or more resources accessible to the server that match the specified tag / value pair. The same form of an HTTP request may be used to specify different types of tag / value pairs, such as identifier numbers, names, etc., using the same URI of the request. The tag / value pair may be specified anywhere in the HTTP request. However, for clarity, the examples herein describe the tag / value pair as being at the end of the URI, which should not be construed as limiting the scope of the claims.

[0017] In various embodiments, a server may process an HTTP request based on a tag / value pair within the HTTP request. A server receiving an HTTP request from a client may initially determine whether the HTTP request includes a tag / value pair. If it is determined that the HTTP request includes a tag / value pair (e.g., specified at the end of the URI), the server may extract the tag / value pair from the HTTP request. The server may then query a resource database based on the tag / value pair. The server may perform the operation specified by the HTTP request on one or more resources that match the tag / value pair in the resource database. The server may return the one or more resources that match the tag / value pair in the resource database to the client that sent the HTTP request to the server.

[0018] In various embodiments, an HTTP request may include multiple tag / value pairs. The server may be configured to identify resources that match all tag / value pairs (AND operation) or at least one tag / value pair (OR operation). The server may determine whether to use an "AND" operation or an "OR" operation to identify (one or more) resources based on the information included in the HTTP request. As an example, multiple tag / value pairs may be included in a Boolean expression. In a Boolean expression, multiple different tag / value pairs may be specified together with a Boolean operator to specify resources that match any specified tag / value pair (e.g., OR operation), resources that match all specified tag / value pairs (e.g., AND operation), sub-resources of resources that match a specified top-level tag / value pair and a specified sub-resource tag / value pair, and any combination thereof.

[0019] In various embodiments, a Representational State Transfer (REST) ​​request, which is a type of stateless HTTP request, may be performed. REST requests are a subset of HTTP requests. REST requests may use a uniform and predefined set of stateless operations. When using REST requests, state may not be maintained between requests.

[0020] In an embodiment, the operation of processing an HTTP request by a server includes processing a label / value pair. A first HTTP request may be received, for example, from a client to perform a first operation. The first operation may be specified by the HTTP request. The first operation may be mapped to one or more other operations. A first field name (e.g., a label) and a first field value (e.g., a value corresponding to the label) recorded in the first HTTP request may be extracted from the first HTTP request. A first query may be defined based on the extracted first field name and first field value. The first query may be executed to identify any resources having a first field value for a first field having a first field name. The first resource may be identified in a first query result set corresponding to the first query. The first operation may be performed on the first resource. One or more other operations to which the first operation is mapped may be performed.

[0021] In various embodiments, a second field name and a second field value recorded in the first HTTP request may be extracted. A second query may be defined based on the extracted first field name, first field value, second field name, and second field value. The second query may be executed to identify any resources having a first field value for a first field having the first field name and a second field value for a second field having the second field name. A second resource may be identified in a second query result set corresponding to the second query. The first operation may be performed on the second resource.

[0022] In various embodiments, a second field name and a second field value recorded in the first HTTP request may be extracted. A second query may be defined based on the extracted first field name, first field value, second field name, and second field value. The second query may be executed to identify any resources having a first field value for a first field having the first field name or a second field value for a second field having the second field name. A second resource may be identified in a second query result set corresponding to the second query. The first operation may be performed on the second resource.

[0023] In various embodiments, a second field name and a second field value recorded in the first HTTP request may be extracted. A second query may be defined based on the extracted second field name and second field value. The second query may be executed to identify any sub-resources of the first resource that have a second field value for a second field having the second field name. The second resource may be identified in a second query result set corresponding to the second query. The first operation may be performed on the second resource.

[0024] In various embodiments, a second resource may be identified in a first query result set corresponding to the first query, and a first operation may be performed on the second resource.

[0025] In various embodiments, a second HTTP request may be received to perform a second operation. A second field name and a second field value may be extracted from the HTTP request. A second query may be defined based on the second field name and the second field value. The second query may be executed to identify any resources having a second field value for a second field having the second field name. If the server determines that no resource has a second field value for any field having the second field name, an error may be presented.

[0026] One or more embodiments described in this specification and / or recited in the claims may not be included in this general summary.

[0027] 2. System Architecture Overview

[0028] Figure 1 is a block diagram illustrating a distributed computing system 100 for identifying HTTP resources 120 using multivariate HTTP requests, according to one or more embodiments. Figure 2A 、 2B 2C are diagrams illustrating the formatting of an HTTP request 200 for identifying a resource 120 according to one or more embodiments. Figure 1 As shown, system 100 includes a server 110 and a client 160. Although only one server 110 and one client 160 are shown, in various embodiments, there may be any number of servers 110 and / or clients 160 coupled to each other via a computer communication system (e.g., a LAN or the Internet). In one or more embodiments, system 100 may include more than one server 110 and / or client 160. Figure 1 More or fewer components may be used than shown. Figure 1 The components shown in can be local or remote from each other. Figure 1 The components shown in the figure can be implemented in software and / or hardware. Each component can be distributed across multiple applications and / or machines. Multiple components can be combined into one application and / or machine. Operations described with respect to one component can be performed by another component instead.

[0029] In an embodiment, system 100 is implemented on one or more digital devices. The term "digital device" generally refers to any hardware device that includes a processor. A digital device can refer to a physical device that executes an application or a virtual machine. Examples of digital devices include computers, tablet computers, laptop computers, desktop computers, netbooks, servers, web servers, network policy servers, proxy servers, general-purpose machines, special-purpose hardware devices, hardware routers, hardware switches, hardware firewalls, hardware firewalls, hardware network address translators (NATs), hardware load balancers, mainframes, televisions, content receivers, set-top boxes, printers, mobile phones, smartphones, personal digital assistants ("PDAs"), wireless receivers and / or transmitters, base stations, communication management equipment, routers, switches, controllers, access points, and / or client devices.

[0030] In one or more embodiments, a user interface refers to hardware and / or software configured to facilitate communication between a user and the system 100. A user interface can render user interface elements and receive input via the user interface elements. Examples of interfaces include graphical user interfaces (GUIs), command line interfaces (CLIs), tactile interfaces, and voice command interfaces. Examples of user interface elements include check boxes, radio buttons, drop-down lists, list boxes, buttons, toggle switches, text fields, date and time pickers, command lines, sliders, pages, and forms.

[0031] In an embodiment, different components of the user interface are specified in different languages. The behavior of the user interface elements is specified in a dynamic programming language such as JavaScript. The content of the user interface elements is specified in a markup language such as Hypertext Markup Language (HTML) or XML User Interface Language (XUL). The layout of the user interface elements is specified in a style sheet language such as Cascading Style Sheets (CSS). Alternatively, the user interface is specified in one or more other languages ​​such as Java, C, or C++.

[0032] In the following description, an embodiment is described in which a client issues a multivariate HTTP request to identify a resource 120 on a server. However, this should not be construed as limiting, as in various other embodiments, the multivariate HTTP request to identify a resource 120 may be performed within a single computing system or application rather than between a server and a client in a distributed computing system.

[0033] In one or more embodiments, client 160 includes an application 165, such as a web browser or other application, that is configured to access data from another application, process, or computer system using the HTTP protocol. Application 165 may include one or more calls to access data or resources using the HTTP protocol according to an application programming interface (API) 170. API 170 may be configured to access data or resources using the HTTP protocol based on field values ​​and / or identifiers of fields having field names. API 170 may reference one of many calls to access data or resources. Client 160 may also include an HTTP interface 175 via which API 170 issues HTTP requests 145 to access data or resources from server 110.

[0034] HTTP request 145 may be a stateless request. HTTP request 145 may be a Representative State Transfer (REST) ​​request that uses a unified and predefined set of stateless operations. A stateless request may be an HTTP request in which no state is maintained between requests. A stateless request may include an HTTP request. An HTTP request may include a normal (e.g., "http") request or a secure (e.g., "https") request.

[0035] In one or more embodiments, a web browser (often referred to as a browser) is a software application for retrieving, presenting, and traversing information resources on the World Wide Web. Information resources can be identified by a Uniform Resource Identifier or Uniform Resource Locator (URI / URL), which can be a web page, image, video, or other piece of content. Although browsers are primarily intended for using the World Wide Web, browsers can also be used to access information provided by a web server in a private network or a file in a file system. In some embodiments, a web browser can be a standalone software application that executes on a client 160 that is communicatively coupled to a server 110 via a computer communication network (e.g., a LAN or the Internet). In some embodiments, the web browser is a component of the system 100 and is specifically configured to cooperate with other components of the system 100 to perform the operations of the system 100. For example, as a component of the system 100, the web browser may not physically display a rendered web page, but rather generate a data table in a memory or data storage device that represents information obtained from the server 110 via an HTTP request.

[0036] In one or more embodiments, server 110 comprises a web server, which is a computer system or application that processes HTTP requests to distribute information on the World Wide Web. The primary function of a web server may be to store, process, and deliver web pages to clients. Web pages delivered by a web server may also include images, style sheets, and scripts in addition to text content. Server 110 may transmit web pages to client 160 and / or application 165 running on client 160, for example, via HTTP over a computer communication network (e.g., a local area network (LAN) or the Internet).

[0037] The server 110 may include a resource database 115 that stores a plurality of resources 120. Each of the resources 120 may include one or more identifiers and associated field values. An identifier may be referred to as a "tag" or "field name," and an identifier may identify a field having a value that may be referred to as a "field value." Fields having field names and associated values ​​may be collectively referred to as tag / value pairs or field name / value pairs. The server 110 may process one or more HTTP requests 145 received from a client 160 via an HTTP interface 125. The HTTP interface 125 may process the received HTTP requests 145 to extract the identifiers and associated field values. The HTTP interface 125 may use the extracted identifiers and associated field values ​​to define a database query 135.

[0038] The received HTTP request 145 may define an operation to be performed on one or more resources 120. A database query 135 may be defined to specify the operation to be performed. The specified operation may also be mapped to one or more other operations. The specified operation may also be transformed before being forwarded to the database interface 130 or before being executed by the database interface 130 on the one or more resources 120. The transformation operation may include converting the name of the instruction associated with the specified operation into the name of a new instruction. Executing the operation specified in the HTTP request 145 may include executing the new instruction resulting from transforming the specified operation.

[0039] The database interface 130 can process the database query 135 and access the resource database 115 based on the database query 135. The database interface 130 can retrieve or perform the specified operation and / or one or more other operations mapped to the one or more resources 120 identified by the database query 135. The database interface 130 can then provide the query / operation results 140 generated by executing the database query 135 on the resource database 115 and / or performing the operation on the one or more resources 120 to the HTTP interface 125. For example, when the database query 135 is to perform an operation on one or more resources 120 in the resource database 115, the database interface 130 can provide a list of all resources 120 on which the operation is to be performed. The list can be a list of field values ​​that match the field name / value pairs in the database query 135. As another example, when the database query 135 is to retrieve one or more resources 120 in the resource database 115, the database interface 130 can provide all resources 120 that have field name / value pairs that match the field name / value pairs in the database query 135.

[0040] After database interface 130 completes processing of database query 135 and provides query / operation result 140 to HTTP interface 125 , HTTP interface 125 may provide HTTP response 150 to client 160 , which includes query / operation result 140 or confirmation of completion of the operation specified by HTTP request 145 .

[0041] Typical APIs for HTTP requests made by a client to a server to access resources stored at the server have different forms, depending on how the HTTP request accesses the resource, e.g., by identification number, name, etc. Such APIs are generally formed similar to the following example:

[0042] http[s]: / / someserver / some / api / path / entityType / entityId / [entitySubProperty / entitySubProperty / […]]

[0043] In this typical approach, references to specific resources according to specific entity types are fixed to entity fields and are usually hard-coded in a storage device such as a database along with the entity identifier.

[0044] In a typical system, when a resource is created, a unique identifier for that resource is created. This unique identifier can be created automatically by the same process that created the resource, or it can be specified by the calling process or the user. The unique identifier can be a pseudo-random sequence of characters that, by itself, has no meaning to the user and serves only as an identifier for the resource. Attributes such as a name that a user can understand and associate with the resource can also be created for the resource. Thus, a typical HTTP API may have multiple commands to access a resource—one command to access a resource by its assigned unique ID, one command to access a resource by its name attribute, and potentially many other commands to access resources based on the values ​​of other attributes.

[0045] One way a typical API solves these problems is to create subresources for a resource so that the resource can be accessed via different subresources. Typical APIs for HTTP requests involving subresources use different API commands, depending on how the resource is addressed. For example, the following HTTP GET request accesses a subresource by its identifier, where {entityId} is the identifier of the resource:

[0046] GET / some / api / version / entityType / byId / {entityId}

[0047] As another example, the following HTTP GET request accesses a subresource by its name, where {entityName} is the name of the resource:

[0048] GET / some / api / version / entityType / byName / {entityName}

[0049] In these examples, the HTTP request API for accessing a subresource by its identifier is different from the HTTP request API for accessing a subresource by its name.

[0050] Another approach used by typical APIs is to use queries to access resources. The APIs used for HTTP query requests may take different forms on different computing systems. For example, the following HTTP GET request will execute the query <somequery>To access resources, the query is a specific query to be performed on matching resources:

[0051] GET / some / api / version / entityType? query= <somequery>

[0052] Another approach that typical APIs use is to attempt to identify and understand entity reference types on the fly. In this approach, the system attempts to automatically identify the type of reference passed to the request. The following HTTP GET request will access a resource based on one of several different resource reference types (specifically, entity name or entity identifier), and the server processing the received HTTP request determines on the fly whether {entityNameOrId} refers to an entity name or an entity identifier:

[0053] GET / some / api / version / entityType / {entityNameOrId}

[0054] Processing the above HTTP request can dynamically attempt to determine whether the request should match {entityNameOrId} to a resource name or resource identifier. Furthermore, in some cases, different resources may have names that match the specified {entityNameOrId} and identifiers that match the specified {entityNameOrId}, leading to ambiguous results.

[0055] The embodiments described herein address these issues by providing flexible access to system entities via an API. Objects created as resources may also be referred to as entities. According to embodiments, a resource can be accessed using a single API call by simply changing the API call's payload, which specifies the fields used to identify the resource being accessed. Furthermore, multiple resources can be accessed using a single API call by using Boolean operators to combine different field names and values ​​for different resources within the call's payload.

[0056] Figure 2A 、 2B 2C is a diagram illustrating the formatting of an HTTP request for identifying an HTTP resource according to one or more embodiments. Figure 2A In the command, "SP" represents space, "CR" represents carriage return, and "LF" represents line feed. Figure 2A The diagram illustrates the format of an HTTP request. The request line begins with an HTTP method (e.g., GET, DELETE, PUT, POST, HEAD, etc.). The URL following the method indicates where the HTTP request is being sent. The version indicates the version of HTTP according to which the request is formatted. All lines following the request line are optional. Following the request line are a series of header lines, each of which begins with a header field name followed by a value. As an example, a header line may include the field name HOST followed by a URL to indicate the host where the resource is located. After the header line, a blank line indicates that the request body, identified as the entity body, follows. The request body may include the payload of the request. For example, if the request is to apply a patch to one or more resources, the entity body of the request may include the patch to be applied.

[0057] Figure 2B The following is a more detailed illustration of the embodiment described herein. Figure 2A The portion of an HTTP request line shown in . The request begins with a method (e.g., GET, PUT, etc.). After the method and a space is the URL, which begins with the protocol to be used. HTTP requests can use one of two protocols: the standard protocol ("http") and the secure protocol ("https"). After the protocol is the standard ": / / " string that separates the protocol from the host / domain (HOST / DOMAIN), followed by the host / domain. For example, this could be an Internet domain name ending in ".com". Following the host / domain are fields separated by " / " characters, including the API and the entity type (ENTITY TYPE). After the entity type is the entity identifier (ENTITY IDENTIFIER). The entity identifier can include a label / value pair or a Boolean expression to identify one or more resources in the resource database of the server being accessed. The entity identifier can have a <referencetype> : <referencevalue>A scheme is defined in which referenceType matches a property of resource 120 and referenceValue refers to the actual value of the specified property of resource 120, which can be used to access resource 120. Unlike traditional systems where prefixes are embedded within the URL to specify the property to be matched by the HTTP request, the equivalent of the traditional prefix is ​​provided in the entity identifier. <referencetype>In this way, the URL used for HTTP request 145 can be the same for many different reference types. Thus, server 110 can use a single handler to process HTTP request 145 regardless of the type of resource used to access resource 120. <referencetype>.

[0058] Figure 2C The composition of entity identifiers according to various embodiments is illustrated. Resources can be specified in terms of label / value or field name / value pairs. These pairs can be used together in a Boolean expression to more specifically identify one or more resources that the expression requests from a server. For example, a label can be specified as a tag (e.g., "TAG1") followed by a token (e.g., a colon (":")) followed by a value corresponding to the tag (e.g., "VALUE1"). Although a colon is provided as an example, in various embodiments, different characters can be used for the token that separates the label from the value. In addition, brackets can be used to nest Boolean operators and expressions, which are to be executed in order according to their position within the nested brackets.

[0059] For example, TAG1 may be "name" to indicate a field specifying the name of a resource. VALUE1 corresponding to TAG1 "name" may be "MyEntity" to specify that the corresponding resource has the name "MyEntity". TAG2 may be "id" to indicate the identifier of the resource. VALUE2 corresponding to TAG2 "id" may be "MyId" to specify that the corresponding resource has the identifier "MyId". A request seeking to obtain all resources that have both the name "MyEntity" and the id "MyId" may include the entity identifier "name:MyEntity AND id:MyId", while a request seeking to obtain all resources that have the name "MyEntity" or the id "MyId" may include the entity identifier "name:MyEntity ORid:MyId".

[0060] In various embodiments, the system may export some resources 120 from the resource database 115 of the first server 110 to the resource database 115 of the second server 110 while maintaining references between the resources 120 exported to the second server 110 and other resources 120 in the first server 110. The resources 120 exported to the second server 110 may be assigned new field name / value pairs that indicate the unique identifier of the original resource 120 in the first server 110. The new field name / value pairs may be in addition to the unique identifier assigned to the resource 120 by the second server 110. The new field name / value pair may have a label "externalId" and a value equal to the value of the original identifier of the resource 120 on the first server 110. Then, the first server 110 and the second server 110 may be smoothly integrated together because the resource 120 exported from the first server 110 to the second server 110 has a field identifying the unique identifier of the resource 120 on the second server 110 and the corresponding original unique identifier on the first server 110. An HTTP request to the first server 110 to access the exported resource 120 existing on the second server 110 may be processed by the first server 110. The first server 110 may process the exported resource 120 based on the field name / value pair "externalId" and the value of the exported resource 120. The first server 110 may use the original identifier of the resource 120 on the first server 110 to issue a corresponding HTTP request to the second server 110 to request the exported resource 120. The first server 110 may determine the new unique identifier of the exported resource 120 on the second server 110 and return this information to the client that made the request for the exported resource 120 to the first server 110. The first server 110 may also access the exported resource 120 on the second server 110 by using the unique identifier of the exported resource 120 on the second server 110. The first server 110 may also return the exported resource 120 that the first server 110 accessed from the second server 110 to the client that requested the exported resource 120 from the first server 110.

[0061] In various embodiments, a descriptive identifier may facilitate working with multiple resources 120 within the same resource database 115 simultaneously. The descriptive identifier may facilitate using a resource attribute to identify a resource 120 as a member of a group of resources 120 on the same resource database 115 that share a common value for the resource attribute. Accordingly, a single descriptive identifier may be appropriately applied to multiple resources 120 via a tag. In these embodiments, an HTTP request seeking a tag / value pair that applies to many resources 120 may result in an HTTP response that provides all matching resources 120. In this manner, operations may be performed on all matching resources 120 simultaneously in response to the same HTTP request. Additionally, a query may be included in the entity identifier of an HTTP request to access multiple resources 120, e.g., "query:<platform specificquery> ",in<platform specific query> is a query specific to the server 110 and / or the resource database 115. A query returning a number of resources 120 may facilitate group access to the number of matching resources 120, update properties or attributes on the number of matching resources 120, and / or move from one location to another on the number of matching resources 120 as indicated in the tag / value pairs of the matching resources 120. The following is an example HTTP request to update the number of matching resources 120 accompanying the payload according to embodiments described herein:

[0062] POST(PATCH)http: / / someserver / someApi / entityType / tag:someTag

[0063] {

[0064] "location":"some location definition"

[0065] }

[0066] In this example, all resources 120 with a tag "tag" whose value matches "someTag" can update the tag "location" to "some location definition". In addition, various wildcard characters (e.g., "*", "?") can be used and processed when matching a specified tag value to determine that the matching resources 120 have updated the "location" tag.

[0067] Descriptive identifiers can clearly show which fields should be used to access resource 120. Descriptive identifiers may not require sub-resources, thereby promoting a flat, simple and clean resource structure. Accordingly, a clean and simple API can be used to access resources that use descriptive identifiers, and existing APIs can be modified to use the scheme for descriptive identifiers disclosed herein in a simple and direct manner. An advantage of the scheme specified herein is that many attributes can be assigned to a resource 120, so that sub-resources may not be required. A resource 120 can be specified as a flat entity with many attributes defined according to the scheme, so that the resource 120 can be identified and accessed based on any of these many attributes rather than via sub-resources. Therefore, the HTTP API structure for accessing the resource database 115 can be kept simple, flat and clean, thereby reducing the documentation and maintenance burden associated with a complex sub-resource architecture.

[0068] In various embodiments, descriptive identifiers may also be used to access sub-resources. For example, resource 120 may include one or more tag / value pairs (e.g., TAG1:VALUE1) and one or more sub-resources that also have tag / value pairs (e.g., TAG2:VALUE2). An HTTP request to access sub-resources of resource 120 may include a tag / value pair that matches resource 120 and a tag / value pair that matches sub-resources of resource 120. The tag / value pairs of both resource 120 and sub-resources of resource 120 may be matched to return sub-resources of resource 120. As an example, a sub-resource of resource 120 may be accessed using an HTTP request as follows:

[0069] GET http: / / someserver / someApi / resource / TAG1:VALUE1 / sub-

[0070] resource / TAG2:VALUE2

[0071] Reference below Figure 3 Examples are given of operations performed by the system 100 and its constituent components.

[0072] 3. Example Embodiments

[0073] Figure 3 is a flowchart illustrating the processing of a multivariate HTTP request for identifying an HTTP resource according to one or more embodiments. Figure 3 One or more operations shown in . Accordingly, Figure 3 The specific order of operations shown in the description should not be interpreted as limiting the scope of one or more embodiments. For the sake of clarity, detailed examples are described below. The components and / or operations described below should be understood as a specific example that may not apply to certain embodiments. Accordingly, the components and / or operations described below should not be interpreted as limiting the scope of any claim.

[0074] In various embodiments, a system including a computing processor (e.g., Figure 1 The processing performed by the server 110 can process a multivariate HTTP request for identifying an HTTP resource. For example, consider a resource 120 stored in the resource database 115 having the following attributes:

[0075]

[0076] In operation 302, the server 110 may receive an HTTP request 145 to perform an operation. The HTTP request 145 may specify an operation to be performed. The operation may be specified to be performed on one or more resources identified by the HTTP request 145. Examples of operations that may be specified to be performed by the HTTP request 145 include POST, DELETE, GET, and PUT.

[0077] Server 110 may receive HTTP request 145 via HTTP interface 125. HTTP request 145 may include, for example, one of the following example HTTP GET requests:

[0078] GET http: / / someserver / someAPI / entityType / id:someId

[0079] GET http: / / someserver / someAPI / entityType / name:someEntityName The client 160 can use any of the above example requests to access the resource with id "someId" and name "someEntityName".

[0080] In operation 304, the operation to be performed specified by HTTP request 145 in operation 302 can be mapped to one or more other operations. For example, the operations (e.g., HTTP requests) POST, DELETE, GET, and PUT can be mapped to one or more other operations to be performed, including Create, Retrieve, Replace, Update, and Delete. For example, a request POST can be mapped to "Replace" or "Update." As another example, a request GET can be mapped to "Retrieve." In various embodiments, any originally specified operation or request can be mapped to any one or more mapped operations. In various embodiments, the mapping of the originally specified operation can include a one-to-one correspondence with the originally specified operation.

[0081] In operation 306, the field names and corresponding field values ​​may be extracted from the HTTP request 145. The HTTP interface 125 may extract the field names and corresponding field values. The HTTP interface 125 may search for the presence of a marker (e.g., ":" or a colon) within the entity identifier field of the HTTP request 145. If the marker is not present, the HTTP interface 125 may determine that the HTTP request 145 is a legacy HTTP request or a primary access mode and treat the HTTP request 145 accordingly. Such a primary access mode may simply specify an identifier (e.g., "someId") within the entity identifier without specifying a tag or field name. If the marker is present in the entity identifier field of the HTTP request 145, the HTTP interface 125 may determine that the HTTP request 145 is a secondary access mode and continue to identify the tag or field name before the marker. In various other embodiments, the marker may include another character, such as a semicolon, a comma, a hyphen, a dash, a period, an exclamation point, a question mark, a tilde, an ampersand, a caret, an asterisk, or any other character that may be defined as recognizable as separating a field name from a field value.

[0082] In some embodiments, HTTP interface 125 may search for the presence of a prefix within the entity reference of HTTP request 145. If the prefix is ​​present, then HTTP interface 125 may determine that HTTP request 145 is a legacy HTTP request or a primary access mode and treat HTTP request 145 accordingly. Such a primary access mode may simply specify an identifier (e.g., "someId") or other field value within the entity identifier based on the prefix used in the entity reference of HTTP request 145. If the prefix is ​​not present, then HTTP interface 125 may determine that HTTP request 145 is a secondary access mode and continue processing the entity identifier to identify one or more field names or tags and field values ​​and corresponding Boolean relationships.

[0083] By identifying one or more entities to be accessed before processing HTTP request 145 to access specified entities within resource database 115, there is no need to rewrite existing handlers for legacy HTTP requests 145. Thus, embodiments are backward compatible with existing systems that use legacy HTTP requests 145.

[0084] In operation 308, the HTTP interface 125 may define a query based on the field names and field values ​​extracted from the HTTP request 145 in operation 306. The HTTP interface 125 may process any Boolean expressions in the HTTP request 145 to construct a query accordingly. The HTTP interface 125 may send the defined query as a database query 135 to the database interface 130. The HTTP interface 125 may also specify one or more operations to be performed on the database interface 130. For example, the HTTP interface 125 may define a database query 135 to specify the operations to be performed. The HTTP interface 125 may also map the specified operations to one or more other operations.

[0085] The HTTP interface 125 may also transform the specified operation before forwarding the operation to the database interface 130. The database interface 130 may transform the operation specified by the HTTP interface 125 in the database query 135 before performing the operation on one or more resources 120. Transforming the operation may include transforming the name of the instruction associated with the specified operation into the name of a new instruction. Executing the operation specified in the HTTP request 145 may include executing the new instruction resulting from transforming the specified operation.

[0086] In operation 310, database interface 130 may execute database query 135 to identify resources 120 in resource database 125 that have field values ​​for the fields having the field names extracted from HTTP request 145 in operation 306. In embodiments where HTTP request 145 specifies multiple field values ​​and each field value corresponds to a specified field name, database interface 130 may identify each resource 120 according to database query 135 based on any Boolean expression included in HTTP request 145.

[0087] In operation 312 , the database interface 130 may determine whether any of the resources 120 identified by executing the database query 135 are present. The database interface 130 may analyze the results of executing the database query 135 to determine whether the results include any of the resources 120 .

[0088] In operation 314, if the results of executing the database query 135 in operation 310 include one or more resources 120, the database interface 130 may identify the resources 120 in the query results. If more than one resource 120 is present in the query results, the database interface 130 may identify a resource 120 based on any of a number of different criteria, such as, for example, the resource 120 that was ranked first in the list of resources returned from the results of executing the database query 135 in operation 310.

[0089] In operation 316, an operation may be performed on the identified resource 120. The operation performed may be as originally specified in the HTTP request 145, converted from the originally specified operation, mapped from the originally specified operation, or included in the database query 135. For example, if the HTTP request 145 specifies that a field of the resource 120 be updated, then an operation to update the field may be performed in operation 316. After the operation is performed on the identified resource 120, the identified resource 120 may be returned to the client 160. The identified resource 120 may be returned to the client 160 by returning the identified resource 120 in the query / operation result 140 to the HTTP interface 125, which may then return the resource 120 to the client 160 as part of the HTTP response 150. If no operation was originally specified in the HTTP request 145 and no operation to be performed on the identified resource 120 was included in the database query 135, then the identified resource 120 may simply be returned to the client 160. Identifiers or field values ​​of resources 120 may be returned to client 160 instead of the entire resource 120. Server 110 may return any of the following in HTTP response 150: a list of resources 120 that match HTTP request 145, a list of resources 120 that match HTTP request 145 after being updated according to HTTP request 145, a list of properties of resources 120 that match HTTP request 145 (e.g., a list of unique identifiers of resources 120 that match HTTP request 145), and / or a confirmation that HTTP request 145 has been processed by server 110.

[0090] In operation 318, the one or more other operations to which the operation specified in the HTTP request 145 was mapped in operation 304 may be performed. The one or more other operations to which the operation was mapped may be performed on the identified resource 120.

[0091] In operation 320, the database interface 130 may determine whether the query results generated by executing the database query 135 in operation 310 include any more resources 120 that have not been operated on in operation 316. If the query results do not include any additional resources 120, then the method may end. In some embodiments, the resources 120 included in the query results may be returned together in the query / operation results 140. The resources 120 may then be returned to the client 160 by the HTTP interface 125 in the HTTP response 150.

[0092] In operation 322, if there are additional resources 120 in the query results as determined in operation 320, another resource 120 in the query results can be identified in the query results. The database interface 130 can identify the another resource 120 based on any of a number of different criteria, such as, for example, the resource 120 that is next in the list of resources returned from the results of executing the database query 135 in operation 310. After identifying the another resource 120 in the query results, the method can proceed again to operation 316.

[0093] In operation 324, an error message may be issued if the resource 120 is not included in the results of executing the database query 135 in operation 310. The error message may initially be reported by the database interface 130 in the query / operation result 140 to the HTTP interface 125, which may then pass the error message to the client 160 in the HTTP response 150.

[0094] Figure 4 is a block diagram illustrating a distributed computing system 400 for identifying a client asset 420 in a server 410 corresponding to an asset 480 in a client 460 using a multivariate HTTP request, according to one or more embodiments. Distributed computing system 400 may be an embodiment of distributed computing system 100, server 410 may be an embodiment of server 110, and client 460 may be an embodiment of client 160. HTTP interface 425 may be an embodiment of HTTP interface 125, database interface 430 may be an embodiment of database interface 130, and resource database 415 may be an embodiment of resource database 115. Client asset 420, including an identifier and a client ID, may be an embodiment of resource 120. Database query 435 may be an embodiment of database query 135, and query / operation result 440 may be an embodiment of query / operation result 140. HTTP interface 475 may be an embodiment of HTTP interface 175, HTTP API 470, including a field identifier and a client ID, may be an embodiment of HTTP API 170, and application 465 may be an embodiment of application 165. HTTP request 445 may be an embodiment of HTTP request 145 , and HTTP response 450 may be an embodiment of HTTP response 150 .

[0095] Distributed computing system 400 can provide seamless integration between different software applications operating within distributed computing system 400. For example, within distributed computing system 400, a software application can migrate from one instance of a computing client 460 or server 410 to another instance of a computing client 460 or server 410. As another example, two separate software applications (e.g., an application 465 on client 460 and a resource database 415 on server 410) can track the same digital asset or data object. The digital asset or data object can be a client asset 420 stored in resource database 415 located on server 410 and also maintained locally as asset 480 by application 465 on client 460. Each client 460 and server 410 that tracks the same digital asset or data object can have a different unique identifier or ID associated with the digital asset or data object. Application 465 on client 460 can assign a client ID to an asset 480, while resource database 415 on server 410 can assign a server ID to the corresponding client asset 420 stored within resource database 415. In a typical system, both the application 465 on the client 460 and the resource database 415 on the server 410 need to track two identifiers: a server ID and a client ID, associated with an asset 480 on the client 460 and the corresponding client asset 420 on the server 410. This can lead to problems maintaining consistency across the distributed computing system 400.

[0096] In the embodiments disclosed herein, client assets 420 stored in resource database 415 on server 410 that correspond to assets 480 in application 465 on client 460 can be accessed by application 465 on client 460 using only the client ID and not the server ID associated with the client assets 420 stored in resource database 415. This provides a seamless way for client 460, as the primary physical owner of asset 480, to maintain corresponding client assets 420 stored in resource database 415 on server 410.

[0097] In an embodiment, client 460 can create an asset 480 and assign a unique client ID to asset 480. Client 460 can maintain asset 480 within application 465 on client 460. During integration between server 410 and client 460 within distributed computing system 400, client 460 can export asset 480 to server 410. Server 410 can then create client asset 420 as a copy of asset 480, assign a new server ID to client asset 420, and store the client ID of the original asset 480 within client asset 420 as a value in a field identified by a field identifier or tag. By way of example, the field identifier can be "ExternalID." All assets and resources stored in resource database 415 of server 410 can be assigned a server ID, each server ID being unique within resource database 415. Each asset and resource stored in resource database 415 can be directly accessed using the corresponding assigned server ID. Furthermore, those client assets 420 created by the server 410 based on the assets 480 exported to the server 410 from the client 460 may also be directly accessed using a combination of the "ExternalID" field identifier and the original client ID associated with the asset 480. Thus, the client 460 may access the client assets 420 corresponding to the exported assets 480 stored in the resource database 415 using an HTTP request that includes both the "ExternalID" field identifier and the original client ID associated with the asset 480. For example, such an HTTP request may include the following URL:

[0098] http: / / serverName / somePath / ExternalID:<client ID> or

[0099] https: / / serverName / somePath / ExternalID:<client ID>, where "serverName (server name)" is the domain name service (DNS) server name corresponding to server 410, "somePath (certain path)" is the path defined by server 410 for accessing assets stored in resource database 415, "ExternalID" is the field name or label corresponding to the original client ID stored in client assets 420, ":" is a delimiter defined to separate the field name and the field value stored in the field associated with the field name, and <client ID (client ID)> is the field value including the original client ID of exported assets 480. In various embodiments, as shown in this exemplary embodiment, different field names may be used instead of "ExternalID". Similarly, the "serverName" and "somePath" provided here are only examples, and other embodiments may use different names or text strings for these purposes.

[0100] Any asset stored in client assets 420 in resource database 415 of server 410 can also be directly accessed using the server ID assigned by server 410 to the corresponding client assets 420, for example, by using an HTTP request specifying the server ID assigned by server 410. Examples of such HTTP requests may include the following URLs:

[0101] http: / / serverName / somePath / <id>or

[0102] https: / / serverName / somePath / <server ID>, where "<server ID (Server ID)>" is the server ID uniquely identifying the client asset 420 in the resource database 415 assigned by the server 410.

[0103] In the embodiments described herein, each of the client 460 and the server 410 is independent of each other in terms of addressing and identifying the resources and assets created, tracked, and managed on their respective systems. When the client 460 exports the asset 480 to the server 410 for storage in the resource database 415 as the imported client asset 420, the server 410 can assign a unique server ID to the imported client asset 420 to be compatible with the server's own addressing and identification scheme for other server assets and resources. At the same time, the server 410 can track the original client ID of the imported client asset 420. Thus, the client 460 can use the client ID originally assigned to the asset 480 exported to the server 410 to access the imported client asset 420 without having to care about the server ID assigned by the server 410 to the imported client asset 420. This becomes particularly beneficial when the client 460 exports the same asset 480 to many different instances of the server 410. In each instance of the server 410 to which the asset 480 is exported, the client does not need to track the server ID associated with the exported asset 480. In addition, the server 410 can modify the server ID associated with the imported client asset 420 without notifying the client 460 that had exported the corresponding exported asset 480 to the server 410. Regardless of what the server 410 assigns as the server ID to the imported client asset 420, the client 460 can still use the client ID associated with the exported asset 480 to access the imported client asset 420.

[0104] In an embodiment, the application 465 can perform functions and manage various assets 480, such as data objects related to work orders. The application 465 can include an asset maintenance service for maintaining the assets 480. In the integration with other systems and databases in the distributed computing system 400, the application 465 can cause a client asset 420 corresponding to the asset 480 for which the application 465 performs functions in the client 460 to be created in the resource database 415 of the server 410. The server 410 can include an asset monitoring service for monitoring the assets 480 of the application 465. When the client asset 420 is created in the resource database 415, a new field named "ExternalID" can be added to the client asset 420, and this new field is not included in the assets 480 exported by the application 465. When the client asset 420 is created and stored in the resource database 415, the server 410 can store the client ID of the asset 480 in the application 465 in the field named "ExternalID".

[0105] An application running on or working with the server 410 can directly use the server ID assigned by the server 410 to the corresponding asset to access any asset stored in the resource database 415, whether they are client assets 420 or other assets created and / or managed by the server 410 independently of the client 460. For example, the URL of an HTTP request for accessing an asset can be:

[0106] http: / / server / assetMonitoring / api / v2 / assets / <server ID>, where "server" is the DNS server name corresponding to the server 410, "assetMonitoring / api / v2 / assets" is the path defined by the server 410 for accessing the assets stored in the resource database 415, and "<server ID>" is the unique server ID assigned to the asset being accessed.

[0107] The application 465 can access the client asset 420 corresponding to the exported asset 480 using the originally assigned client ID without having to worry about the server ID assigned to the corresponding client asset 420 imported from the application 465. For example, the URL of an HTTP request to access the imported client asset 420 corresponding to the exported asset 480 may be: http: / / server / assetMonitoring / api / v2 / assets / ExternalID:<client ID> , where "ExternalID" is a field name or label corresponding to the originally assigned client ID in the imported client asset 420 stored in the resource database 415, ":" is a marker defined to separate a field name from a field value stored in a field associated with the field name, and<client ID> is a field value that includes the original client ID of the exported asset 480. The application 465 may not track the server ID assigned by the server 410 to the imported client asset 420 corresponding to the exported asset 480.

[0108] In an embodiment, the application 465 may pass an instruction or instruction name for the server 410 to execute on the client asset 420 corresponding to the exported asset 480 as the payload of the HTTP request 445. In an embodiment, the application 465 may pass a patch to be applied to the client asset 420 corresponding to the exported asset 480 as the payload of the HTTP request 445. In an embodiment, the application 465 may pass an instruction or data object to be delivered to or stored in the client asset 420 corresponding to the exported asset 480 as the payload of the HTTP request 445.

[0109] In an embodiment, one or more instructions or operations specified by application 465 as the payload of HTTP request 445 may be converted by server 410 before being applied to client asset 420 corresponding to exported asset 480. For example, client 460 may be a little endian or big endian machine, while server 410 may be the other of the little endian and big endian machines. The instructions or operations specified by client 460 as the payload of HTTP request 445 sent to server 410 to be applied to client asset 420 corresponding to exported asset 480 may be specific to the endian type of client 460. Since server 410 is of a different endian type, server 410 may convert the instructions or operations into corresponding instructions or operations that will perform the intended function on client asset 420. In other words, when the endianness of client 460 and server 410 differs, little endian instructions or operations may be converted to big endian instructions or operations, and vice versa.

[0110] 4. Other Matters; Extension

[0111] Embodiments are directed to a system having one or more devices comprising a hardware processor and configured to perform any of the operations described herein and / or in any of the following appended claims.

[0112] In an embodiment, a non-transitory computer-readable storage medium comprises instructions that, when executed by one or more hardware processors, cause performance of any of the operations described herein and / or recited in any claim.

[0113] According to one or more embodiments, any combination of the features and functions described herein may be used. In the foregoing description, embodiments have been described with reference to many specific details, which may vary from one embodiment to another. Therefore, the description and drawings should be viewed in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention and what the applicant intends to be the scope of the invention is the literal and equivalent scope of the resulting claims in the specific form of the set of claims resulting from this application, including any subsequent corrections.

[0114] 5. Hardware Overview

[0115] According to one embodiment, the technology described herein is implemented by one or more special-purpose computing devices. Special-purpose computing devices can be hard-wired to perform the present technology, or can include digital electronic devices that are persistently programmed to perform the present technology, such as one or more application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or network processing units (NPUs), or can include one or more general-purpose hardware processors that are programmed to perform the present technology according to program instructions in firmware, memory, other storage devices, or combinations. Such special-purpose computing devices can also implement the present technology by combining customized hard-wired logic, ASICs, FPGAs, or NPUs with customized programming. Special-purpose computing devices can be desktop computer systems, portable computer systems, handheld devices, networking devices, or any other devices that implement the present technology in combination with hard-wiring and / or program logic.

[0116] For example, Figure 5 5 is a block diagram illustrating a computer system 500 upon which embodiments of the present invention may be implemented. Computer system 500 includes a bus 502 or other communication mechanism for communicating information and a hardware processor 504 coupled with bus 502 for processing information. Hardware processor 504 may be, for example, a general-purpose microprocessor.

[0117] Computer system 500 also includes a main memory 506, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 502 for storing information and instructions to be executed by processor 504. Main memory 506 may also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 504. Such instructions, when stored in a non-transitory storage medium accessible to processor 504, render computer system 500 a special-purpose machine customized to perform the operations specified in the instructions.

[0118] Computer system 500 also includes a read only memory (ROM) 508 or other static storage device coupled to bus 502 for storing static information and instructions for processor 504. A storage device 510, such as a magnetic or optical disk, is provided and coupled to bus 502 for storing information and instructions.

[0119] The computer system 500 may be coupled to a display 512, such as a cathode ray tube (CRT), via the bus 502 for displaying information to a computer user. An input device 514, including alphanumeric and other keys, is coupled to the bus 502 for communicating information and command selections to the processor 504. Another type of user input device is a cursor control 516, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 504 and for controlling movement of a cursor on the display 512. Such input devices typically have two degrees of freedom along two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to specify a position in a plane.

[0120] The computer system 500 can implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with the computer system, makes the computer system 500 a special-purpose machine or programs the computer system 500 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by the computer system 500 in response to the processor 504 executing one or more sequences of one or more instructions contained in the main memory 506. These instructions can be read into the main memory 506 from another storage medium, such as the storage device 510. Execution of the sequences of instructions contained in the main memory 506 causes the processor 504 to perform the process steps described herein. In alternative embodiments, hardwired circuitry can be used in place of or in combination with software instructions.

[0121] As used herein, the term "storage medium" refers to any non-transient medium that stores data and / or instructions that cause a machine to operate in a specific manner. Such storage media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 510. Volatile media include dynamic memory, such as main memory 506. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage medium, CD-ROMs, any other optical data storage medium, any physical medium with a pattern of holes, RAM, PROM and EPROM, FLASH-EPROM, NVRAM, any other memory chip or cartridge, content addressable memory (CAM), and ternary content addressable memory (TCAM).

[0122] Storage media are distinct from, but may be used in conjunction with, transmission media. Transmission media participate in the transmission of information between storage media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires comprising bus 502. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0123] Carrying one or more sequences of one or more instructions to the processor 504 for execution may involve various forms of media. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the instructions into the computer's dynamic memory and then send the instructions over a telephone line using a modem. A modem local to the computer system 500 may receive the data on the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data carried in the infrared signal, and appropriate circuitry may place the data on the bus 502. The bus 502 carries the data to the main memory 506, from which the processor 504 retrieves and executes the instructions. The instructions received by the main memory 506 may optionally be stored on the storage device 510 before or after being executed by the processor 504.

[0124] Computer system 500 also includes a communication interface 518 coupled to bus 502. Communication interface 518 provides two-way data communication coupled to network link 520, wherein network link 520 is connected to local network 522. For example, communication interface 518 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection to a telephone line of a corresponding type. As another example, communication interface 518 can be a LAN card that provides a data communication connection to a compatible local area network (LAN). Wireless links can also be implemented. In any such implementation, communication interface 518 sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

[0125] Network link 520 typically provides data communication to other data devices through one or more networks. For example, network link 520 can provide a connection to host computer 524 or to data equipment operated by Internet Service Provider (ISP) 526 through local network 522. ISP 526, in turn, provides data communication services through the global packet data communication network now commonly referred to as the "Internet" 528. Both local network 522 and Internet 528 use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 520 and through communication interface 518 are example forms of transmission media that carry digital data to and from computer system 500.

[0126] Computer system 500 can send messages and receive data (including program code) through the network, network link 520, and communication interface 518. In the Internet example, server 530 can transmit the requested code for an application program through Internet 528, ISP 526, local network 522, and communication interface 518.

[0127] The received code may be executed by processor 504 as it is received and / or stored in storage device 510 or other non-volatile storage for later execution.

[0128] In the foregoing description, embodiments of the present invention have been described with reference to numerous specific details that may vary from embodiment to embodiment. The description and drawings should therefore be viewed in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what applicants intend as the scope of the invention, is the literal and equivalent scope of the claims issued from this application in their specific form, including any subsequent amendments.< / id> < / referencetype> < / referencetype> < / referencevalue> < / referencetype> < / somequery> < / somequery>

Claims

1. A method for performing an operation on a resource based on a hypertext transfer protocol request, comprising: receiving, by the server from the client, a first hypertext transfer protocol request including (a) a character string identifying a target resource using a location of the target resource and (b) a name of a first instruction associated with a first operation; identifying, in the string of the first hypertext transfer protocol request, a first tag / value pair comprising a first field name and a first field value, a second tag / value pair comprising a second field name and a second field value, and a Boolean operator between the first field value and the second field name, the Boolean operator specifying a Boolean relationship between the first tag / value pair and the second tag / value pair; defining a first query based on a first field name, a first field value, a second field name, a second field value, and the Boolean operator, wherein the first query includes the Boolean relationship between the first label / value pair and the second label / value pair; A first query is performed to identify a resource, wherein the resource comprises one of: (a) when the Boolean operator is "AND": a first resource set having both a first field value for a first field having a first field name and a second field value for a second field having a second field name; or (b) when the Boolean operator is “OR”: a second resource set having at least one of a first field value for a first field having a first field name or a second field value for a second field having a second field name; In response to executing a first query, identifying a first resource in a first query result set corresponding to the first query; converting a name of the first instruction into a name of a second instruction, wherein the first instruction is of a first endian type and the second instruction is of a second endian type different from the first endian type; as well as The first operation specified in the first hypertext transfer protocol request is performed on the first resource at least by executing the second instruction.

2. The method of claim 1, further comprising: identifying a second resource in a first query result set corresponding to the first query; as well as Perform a first operation specified in the request on the second resource.

3. The method of any one of claims 1-2, wherein identifying the first tag / value pair comprises: It is determined that the first hypertext transfer protocol request includes a field separator marker separating a first field name from a first field value.

4. The method according to any one of claims 1 to 2, wherein the first operation comprises: A payload included in the first hypertext transfer protocol request is applied to the first resource.

5. The method of any one of claims 1-2, wherein the first HTTP request comprises one or more of: a stateless request, a stateless request in which no state is maintained between requests, a representative state transfer request, or a secure HTTP request.

6. The method of any one of claims 1-2, wherein the first field name and the first field value are at the end of the first hypertext transfer protocol request.

7. The method of claim 4, wherein: The second resource is a different resource than the first resource; and Both the first resource and the second resource are accessed using a single call in a first hypertext transfer protocol request.

8. The method of claim 7, wherein: The first resource comprises a first resource type, and the second resource comprises a second resource type different from the first resource type.

9. The method of claim 7, wherein: The second resource is not a child resource of the first resource.

10. A system for performing an operation on a resource based on a hypertext transfer protocol request, comprising: at least one device; The system is configured to perform the method according to any one of claims 1 to 9.

11. A non-transitory computer-readable storage medium comprising instructions that, when executed by one or more hardware processors, cause the method of any one of claims 1-9 to be performed.

12. An apparatus for performing an operation on a resource based on a hypertext transfer protocol request, comprising: processor; as well as A memory coupled to the processor and having instructions stored thereon, which, when executed by the processor, cause the processor to perform the method of any one of claims 1-9.

Images