The Processing Time in The Range Search Test
Round-trip Communications in The Range Search Test
WARP (Web API Relay Protocol) is a relay protocol for Web APIs. Compared to conventional Web API design patterns, WARP can improve not only the efficiency of data linkage but also versatility, extensibility, affinity, practicality, maintainability, integrity, cooperativeness, dispersibility and consistency. Moreover, WARP is a “Next-Generation Web API” that can further synergize with cooperation with cloud computing, AI, block chains, IoT, IaaS, Paas, SaaS, BaaS, RDBMS, KVS, NoSQL and etc.. (WARP-WG is a group promoting technical standardization of WARP.)
ω=2π/T(s¯¹=/s) Currently, queries of “name=value” format (Nama Value Line query / NVL query) adopted by many conventional Web APIs have various problems. For example, as the condition search pattern increases, the management cost of the request parameter increases. Also, as the search conditions become more complex, the load on the network and system resources will increase. WARP is being developed by WARP-WG in order to solve these various problems that many conventional Web APIs have hitherto possessed.
For example, in the case of NVL Query, the following query syntax tends to be formed. If the Web API service does not provide the conditional parameters necessary for the search, Web API clients will be forced to further filter the result of multiple request, or the Web API service developer will have to add conditional parameters: NVL Query
In WARP, we can use the HTTP request line of WARP Query as below. As a result, WARP can acquire search results matching requirements in a single step without adding conditional parameters, so WebAPI servers can improve processing speed, suppress increase in request parameter and reduce system resource load: WARP QueryPlease refer to the Benchmark Test page and the WARP Solutions page for above-mentioned evidences and detailed WARP superiority.
WARP has enabled “multiple resource simultaneous access” to vertical resources (internal systems) and horizontal resources (external systems) as well as simultaneous access to multiple endpoints. This eliminates the need for Web API clients to call the multiple resources multiple times, which makes it possible to improve the data linking processing speed and reduce the resource cost as compared with conventional methods. By linking the Web API and the Web API, it is also possible to absorb differences in specifications of multiple Web API services and improve development efficiency. WARP Query
WARP has enabled parallel processing as well as simultaneous access to multiple resources. This eliminates the need for Web API clients to implement parallel processing independently, and it is possible to drastically cut the wait time until completion of processing of serial processing: WARP Query
WARP has enabled response key binding processing. This makes it possible to perform flexible intermediate processing of result sets of multiple resources: WARP Query
WARP has enabled a “Open-Cache” mechanism for public information. This makes it possible to realize efficient data operation on the Web API in “Distributed Cooperative System” which shares public data:
WARP has enabled a “Authenticated-Cache” mechanism on Web API servers. This is a mechanism that enables the Web API server to temporarily store the result set obtained from the data resource and the data specified by the Web API client. This enables Web API servers to reuse result sets without reconnecting to the data resource. In addition, Web API clients can reuse syntax and intermediate processing data like variables: WARP Query
WARP has enabled a “Client-Cache” mechanism in Web API clients. This is a mechanism that enables Web API clients to reuse the data based on the cache information of the response data notified by the Web API server. This makes it possible for Web API clients to reduce communication volume and improve processing performance: WARP Response
WARP has enabled interactive transaction processing with Web API clients, which was difficult with stateless HTTP communication. Conventionally, there was a method of completing transaction processing between the Web API server and data resources based on the scenario previously provided by the Web API client. With WARP, Web API clients can control actions from transaction start to commit / rollback based on response results. This enables flexible and dynamic transaction communication between the Web API server / client: WARP Query
GET /user?transaction:=begin&id==1 PUT /user?id==1&name=foo GET /user?id==1&transaction:=commit
WARP has enabled data type processing which was difficult on HTTP URL query string. Conventionally, there was a method of identifying the data type by including data such as JSON and YAML in the payload and making a POST request. This enables strict data processing between Web API clients, Web API servers and data resources: WARP Query
By allowing multifunctional and complicated designs, the convenience of data processing can be easily improved. However, there are cases where such designs become scale costs at the expense of practicality, affinity and versatility. Therefore, WARP realizes practicality, affinity and versatility by pursuing a simpler and more powerful design.
In the WARP Query syntax, a simple evaluation formula known to most engineers is applied, and a practical design has been made to maximize its effect.
As WARP's schema protocol adopts the most common HTTP, its compatibility with devices, clients, backends and services is maintained.
The WARP design pattern is an evolutionary fork of the most popular REST API design pattern among Web APIs, so versatility for Web API service design is maintained.
In many conventional Web API design patterns, especially affinity with RDBMS was one issue. WARP is designed to maintain compatibility with all data resources such as KVS, NoSQL and text based as well as RDBMS. As a result, Web API developers can have more choices for data resources.
In WARP, HTTP request headers can be processed using the URL query string. This is useful in cases where it is costly to handle HTTP request lines directly on the Web API client.
In WARP, HTTP request methods and protocol information can be processed on the URL. This is useful in cases where it is costly to handle HTTP request lines directly on the Web API client.
In WARP, we can set search conditions for each endpoint or resource using WARP configuration. This makes it possible to flexibly adjust the setting of search conditions based on the data resource specifications.
In WARP, Web API document generation and Web API server settings can be configured in WARP Config. This makes it possible to reduce the effort of developing Web API services.
For details of WARP specifications, refer to the Reference page.
For details on parsing WARP Query and other WARP libraries, please refer to WARP Library page.
Cloud Computing, IaaS, PaaS, SaaS, BaaS, IoT, AI, Blockchain, Game, Mobile Application, Web Application, Open Data, In-House Data, Big Data, etc..