HTTP (Hyper Text Transport Protocol) caching method and device suitable for RESTful API (Application Program Interface)

Abstract

The invention provides an HTTP (Hyper Text Transport Protocol) caching method and device suitable for a RESTFul API (Application Program Interface). According to the HTTP caching method suitable for the RESTFul API, a caching service layer is arranged between an HTTP request end and an HTTP server end, the HTTP request end is in communication connection with the caching service layer, and the caching service layer is in communication connection with the HTTP server end; the method comprises the steps that a cache service layer obtains a response result based on a received HTTP request, sends the response result to an HTTP request end and processes cache data of the cache service layer based on the response result, and the HTTP request is from the HTTP request end. By setting the cache service layer, the data of the HTTP request is firstly obtained in the cache service layer, the timeliness of the request is ensured, and the cache service layer is added without additionally adding equipment, so that the universality is enhanced. Therefore, the purpose of improving timeliness and universality is achieved.

Description

Technical Field

[0001] The present invention belongs to the field of network technologies, and in particular, relates to an HTTP caching method and device applicable to RESTFul APIs. Background Art

[0002] HTTP caching refers to the technology of storing the response result of a certain request for reuse in subsequent related requests. Initially, it was mainly used to cache static web page content. With the development of technology, HTTP-based API services began to emerge. Since the content of their responses is dynamically generated, they are generally not cacheable by third-party HTTP caching services.

[0003] Currently, the improvements to HTTP caching mainly focus on the following aspects:

[0004] Firstly, a more in-depth analysis of web page content is carried out, and different resources contained therein are classified, mainly divided into static content and dynamic content, so as to implement different caching strategies for different types of resources. For example, a longer cache expiration time is configured for the static content therein, and with the help of some common Internet basic services, such as the CDN content acceleration network, the caching effect of static resources can be further improved; for the dynamic content therein, a shorter cache duration can be set. Through such more refined cache management, in application scenarios where the timeliness of content is not very sensitive, such as most Internet services, a better caching effect and relatively good timeliness can be obtained compared with traditional HTTP caching. This technical solution is mainly applied to the Internet and has strong versatility, but it is not a solution specifically for HTTP APIs, so the real-time nature of API data cannot be guaranteed.

[0005] Secondly, a method of configuring different HTTP cache times for the data returned by different APIs under the same system is adopted. Different HTTP headers are returned by different APIs, mainly the CACHE-CONTROL instruction, or the expiration time of the data is added to the returned data structure to achieve this. This solution improves the time accuracy of caching to a certain extent by having different expiration times for different data, but obviously still cannot guarantee that the data is the latest at any moment, that is, the real-time nature of the data cannot be guaranteed.

[0006] Thirdly, a complete front-end and back-end system is designed and implemented. The API data is digested through a certain algorithm, and when the data changes, the cached digest is actively updated. By comparing the digest carried in the request with the cached digest, it is determined whether the front-end data needs to be updated, so as to achieve the real-time nature of the data. However, the price is that both the front-end and the back-end are strongly bound to this mechanism. Such a solution is more inclined to customized systems and has poor versatility.

[0007] As described above, the current improvements to HTTP caching mainly focus on static content. For the caching of dynamic resources such as HTTP APIs, either it can have a certain degree of timeliness, but the real-time nature is basically not guaranteed; or an additional system needs to be set up to solve the real-time problem, and the generality is poor. Summary of the Invention

[0008] In view of the problems existing in the prior art, the present invention provides an HTTP caching method and device applicable to RESTFul APIs, which at least partially solve the problems of poor timeliness and generality existing in the prior art.

[0009] In a first aspect, an embodiment of the present disclosure provides an HTTP caching method applicable to RESTFul APIs. A caching service layer is set between the HTTP request end and the HTTP service end. The HTTP request end is communicatively connected to the caching service layer, and the caching service layer is communicatively connected to the HTTP service end. The method includes:

[0010] The caching service layer obtains a response result based on the received HTTP request, sends the response result to the HTTP request end, and processes the cached data of the caching service layer based on the response result. The HTTP request comes from the HTTP request end.

[0011] Optionally, the caching service layer obtains a response result based on the received HTTP request, sends the response result to the HTTP request end, and processes the cached data of the caching service layer based on the response result, including:

[0012] Determine whether the HTTP request needs to read the cached data of the caching service layer. If not, forward the HTTP request to the HTTP service end and receive the response result from the HTTP service end;

[0013] Based on the response result, determine whether it will cause the cached data stored in the caching service layer to become invalid. If so, mark the corresponding cached data as invalid and send the response result to the HTTP request end. If not, directly send the response result to the HTTP request end.

[0014] Optionally, the caching service layer obtains a response result based on the received HTTP request, sends the response result to the HTTP request end, and processes the cached data of the caching service layer based on the response result, including:

[0015] When the HTTP request needs to read the cached data of the caching service layer, determine the HTTP request type. If the request type is write, the caching service layer sends the HTTP request to the HTTP service end, the caching service layer receives the response result from the HTTP service end, marks the corresponding cached data as invalid based on the response result, and sends the response result to the HTTP request end.

[0016] Optionally, determine the HTTP request type, including determining the request type according to the operation specifications for resources in the RESTFul specification.

[0017] Optionally, the cache service layer obtains a response result based on the received HTTP request, sends the response result to the HTTP request side, and processes the cached data of the cache service layer based on the response result, including:

[0018] If the request type is read, determine whether there is data in the cached data stored in the cache service layer that meets the request. If so, read the cached data stored in the cache service layer and generate a response result, and the cache service layer sends the response result to the HTTP request side;

[0019] If not, the cache service layer forwards the HTTP request to the HTTP server. The cache service layer receives the response result from the HTTP server, and after saving the response result, the cache service layer sends the response result to the HTTP request side.

[0020] Optionally, it is used to cache dynamic data returned by HTTP-based APIs.

[0021] In a second aspect, an embodiment of the present disclosure further provides an HTTP cache device applicable to RESTFul APIs, including a cache service layer, where the cache service layer is arranged between the HTTP request side and the HTTP server,

[0022] The cache service layer obtains a response result based on the received HTTP request, sends the response result to the HTTP request side, and the cached data of the cache service layer is processed based on the response result. The HTTP request comes from the HTTP request side.

[0023] Optionally, the cache service layer obtains a response result based on the received HTTP request, sends the response result to the HTTP request side, and the cached data of the cache service layer is processed based on the response result, including:

[0024] Determine whether the HTTP request needs to read the cached data of the cache service layer. If not, forward the HTTP request to the HTTP server and receive the response result from the HTTP server;

[0025] Based on the response result, determine whether it will cause the cached data stored in the cache service layer to become invalid. If so, mark the corresponding cached data as invalid and send the response result to the HTTP request side. If not, directly send the response result to the HTTP request side.

[0026] Optionally, the cache service layer obtains a response result based on the received HTTP request and sends the response result to the HTTP request end. The cache data of the cache service layer is processed based on the response result, including:

[0027] When the HTTP request needs to read the cache data of the cache service layer, the HTTP request type is judged. If the request type is write, the cache service layer sends the HTTP request to the HTTP server. The cache service layer receives the response result from the HTTP server, marks the corresponding cache data as invalid based on the response result, and sends the response result to the HTTP request end.

[0028] Optionally, the cache service layer obtains a response result based on the received HTTP request and sends the response result to the HTTP request end. The cache data of the cache service layer is processed based on the response result, including:

[0029] If the request type is read, it is judged whether there is data in the cache service layer that meets the request. If so, the cache data stored in the cache service layer is read and a response result is generated. The cache service layer sends the response result to the HTTP request end;

[0030] If not, the cache service layer forwards the HTTP request to the HTTP server. The cache service layer receives the response result from the HTTP server, and after saving the response result, sends the response result to the HTTP request end.

[0031] The HTTP caching method and device applicable to RESTFul API provided by the present invention. Among them, the HTTP caching method applicable to RESTFul API first obtains the data of the HTTP request in the cache service layer through setting the cache service layer, ensuring the timeliness of the request, and adding the cache service layer does not require additional devices, enhancing the versatility. Thus, the purpose of improving the timeliness and versatility is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] By describing the exemplary embodiments of the present disclosure in more detail in conjunction with the drawings, the above and other objects, features, and advantages of the present disclosure will become more obvious. Among them, in the exemplary embodiments of the present disclosure, the same reference numerals generally represent the same components.

[0033] Figure 1 It is a principle block diagram of an API service based on HTTP in the prior art;

[0034] Figure 2 It is a principle block diagram of the HTTP caching method applicable to RESTFul API provided by the embodiment of the present disclosure;

[0035] Figure 3Flowchart of the HTTP caching method applicable to RESTful API provided by the embodiments of the present disclosure. Detailed implementation manners

[0036] The embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0037] It should be clear that the embodiments of the present disclosure are described through specific specific examples below. Those skilled in the art can easily understand other advantages and effects of the present disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. The present disclosure can also be implemented or applied through other different specific implementation manners. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that, without conflict, the following embodiments and the features in the embodiments can be combined with each other. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present disclosure without creative efforts belong to the scope of protection of the present disclosure.

[0038] It should be noted that the following describes various aspects of the embodiments within the scope of the appended claims. It should be obvious that the aspects described herein can be embodied in a wide variety of forms, and any specific structure and / or function described herein is illustrative only. Based on the present disclosure, those skilled in the art should understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects described herein can be used to implement a device and / or practice a method. In addition, this device can be implemented and this method can be practiced using other structures and / or functions in addition to one or more of the aspects described herein.

[0039] It should also be noted that the diagrams provided in the following embodiments only illustrate the basic concept of the present disclosure in a schematic manner. The diagrams only show the components related to the present disclosure, rather than being drawn according to the number, shape, and size of the components in actual implementation. The type, quantity, and ratio of each component in its actual implementation can be an arbitrary change, and the component layout type may also be more complex.

[0040] In addition, in the following description, specific details are provided to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the aspects can be practiced without these specific details.

[0041] REST (Representational State Transfer) is a software architecture style aimed at reducing complexity and improving the scalability of the system in the design and development of network applications.

[0042] The HTTP caching method disclosed in this embodiment can be used to cache dynamic data returned by HTTP-based APIs. As long as the APIs provided by the system are developed based on the RESTFul specification, this embodiment can be adopted to seamlessly add a caching service layer between the original client and the server, thereby obtaining benefits such as reduced latency and reduced resource occupancy brought by caching. This embodiment mainly utilizes the RESTFul specification, which is resource-based and has a unified specification for operations on resources, so that reading and writing can be clearly distinguished, and based on this, the real-time nature of data can be ensured. This embodiment can ensure the timeliness of the cached data, which is a key advantage for those systems that need to ensure that the data provided by the API is the latest; second, it can be embedded into the existing business system without perception or only with minor modifications, so that the method of this embodiment has better versatility.

[0043] As Figure 1 shown, a typical HTTP-based API service can be represented as a server that accepts HTTP requests sent by a client, such as a browser, and after a series of calculations, returns an HTTP response containing the dynamic content provided by the API.

[0044] The caching method disclosed in this embodiment is as Figure 2 shown: A caching service layer is added between the original client and the server, and the original requests will be directed to this service. The caching service determines whether the request hits the cached content through the process as Figure 3 shown. If it hits, the cached content will be directly returned to the client through the HTTP response; if it does not hit, the request will be sent to the original server and it will be determined whether the response data returned by the server needs to be cached, and finally the response result will be sent to the client. As an improved solution for HTTP caching, the overall business process of this embodiment is no different from that of traditional HTTP caching services, which is also the reason why this embodiment has strong versatility. The main difference is that the caching service provided by this embodiment can utilize the characteristics of the RESTFul specification to accurately judge the conditions for cache invalidation, thereby ensuring the real-time nature of dynamic data. Its business flow diagram is as Figure 3 shown.

[0045] Classify all requests according to the RESTFul specification and configuration:

[0046] One can divide requests into reads and writes. As the name implies, read-type requests do not change the API data and are the objects of caching; while write-type requests will change the data, causing the data caches of the corresponding resources and even more related resources to become invalid. According to the resource-based feature of the RESTFul specification, it can be directly determined that write-type requests will cause the caches of the corresponding resources to become invalid. In special cases, through configuration, it can be marked that it will cause the caches of other related resources to become invalid.

[0047] Second, there may also be some resources in the system that are not suitable for caching through this solution, and they are excluded through configuration. Similarly, although some resources are excluded from the cache, modifications to these resources may also trigger the invalidation of some related caches, which can also be marked through configuration.

[0048] Therefore, in summary, based on the resource-based nature of the RESTFul specification and the unified specification of operations on resources, it can be clearly determined whether a request will cause certain caches to become invalid and which caches will be affected. For special cases, additional associations can be made through configuration to ensure data timeliness.

[0049] For example, although data A is not cached, data B generated based on data A is in the cache. After data A is modified, data B will also change, and the originally cached data B will become invalid.

[0050] HTTP caching methods applicable to RESTFul APIs specifically include:

[0051] The cache service layer obtains the response result based on the received HTTP request, sends the response result to the HTTP request end, and processes the cached data in the cache service layer based on the response result. The HTTP request comes from the HTTP request end.

[0052] Optionally, the cache service layer obtains the response result based on the received HTTP request, sends the response result to the HTTP request end, and processes the cached data in the cache service layer based on the response result, including:

[0053] Determine whether the HTTP request needs to read the cached data in the cache service layer. If not, forward the HTTP request to the HTTP server and receive the response result from the HTTP server;

[0054] Based on the response result, determine whether it will cause the cached data stored in the cache service layer to become invalid. If so, mark the corresponding cached data as invalid and send the response result to the HTTP request end. If not, directly send the response result to the HTTP request end.

[0055] Optionally, the cache service layer obtains a response result based on the received HTTP request, sends the response result to the HTTP request side, and processes the cache data of the cache service layer based on the response result, including:

[0056] When the HTTP request needs to read the cache data of the cache service layer, judge the HTTP request type. If the request type is write, the cache service layer sends the HTTP request to the HTTP server. The cache service layer receives the response result from the HTTP server, marks the corresponding cache data as invalid based on the response result, and sends the response result to the HTTP request side.

[0057] Optionally, judging the HTTP request type includes judging the request type according to the operation specification of resources in the RESTFul specification.

[0058] Optionally, the cache service layer obtains a response result based on the received HTTP request, sends the response result to the HTTP request side, and processes the cache data of the cache service layer based on the response result, including:

[0059] If the request type is read, then judge whether there is data in the cache stored in the cache service layer that meets the request. If so, read the cache data stored in the cache service layer and generate a response result. The cache service layer sends the response result to the HTTP request side;

[0060] If not, the cache service layer forwards the HTTP request to the HTTP server. The cache service layer receives the response result from the HTTP server, and after saving the response result, sends the response result to the HTTP request side.

[0061] Optionally, it is used to cache dynamic data returned by HTTP-based APIs.

[0062] In a specific scenario, the client in this scenario is the HTTP request side, and the original server is the HTTP server. When a new API request is received, the system process is as follows:

[0063] (1). Judge whether the request requires cache service according to the configuration;

[0064] (2). If it is judged in step (1) that no cache service is required, send the request to the original server and receive the response result;

[0065] (3). Combine the configuration and the type of this request to judge whether it will cause the cache to become invalid. If so, mark the corresponding cache as invalid, and then send the response result to the client, and the process ends;

[0066] (4). If it is determined in step (1) that caching service is required, then according to the operation specifications for resources in the RESTFul specification, determine whether the request type is read or write;

[0067] (5). If it is determined in step (4) that the request type is read, then determine whether the corresponding cached data exists at this time, that is, whether it hits;

[0068] (6). If the cache hits in step (5), then retrieve the data from the cache to form an HTTP response and send it to the client, and the process ends;

[0069] (7). If the cache does not hit in step (5), then send the request to the original server, receive the response result, cache it, and then send the response result to the client, and the process ends;

[0070] (8). If it is determined in step (4) that the request type is write, then send the request to the original server and receive the response result;

[0071] (9). Mark the caches corresponding to its own resources and possible associated resources as invalid, and then send the response result to the client, and the process ends.

[0072] In summary, the caching method of this embodiment can be used to cache HTTP APIs developed according to the RESTFul specification. Compared with other HTTP caching technologies, this embodiment mainly utilizes the characteristics of the RESTFul specification itself, which is resource-based and has unified specifications for resource operations. By classifying HTTP requests into reads and writes, precise cache invalidation control is achieved, and on this basis, the real-time nature of the cached data is ensured. And because the solution provided by this embodiment is generally consistent with the traditional HTTP caching service, its characteristics are mainly within the service and have little invasiveness and destructiveness to the original system. Therefore, this embodiment has good versatility while ensuring data real-time.

[0073] In addition, this embodiment also discloses an HTTP caching device applicable to RESTFul APIs, including a caching service layer, and the caching service layer is arranged between the HTTP request end and the HTTP service end.

[0074] The caching service layer obtains a response result based on the received HTTP request and sends the response result to the HTTP request end. The cached data of the caching service layer is processed based on the response result, and the HTTP request comes from the HTTP request end.

[0075] Optionally, the caching service layer obtains a response result based on the received HTTP request and sends the response result to the HTTP request end. The cached data of the caching service layer is processed based on the response result, including:

[0076] Determine whether the HTTP request needs to read the cached data of the cache service layer. If not, forward the HTTP request to the HTTP server and receive the response result from the HTTP server;

[0077] Based on the response result, determine whether it will cause the cached data stored in the cache service layer to become invalid. If so, mark the corresponding cached data as invalid and send the response result to the HTTP request side. If not, directly send the response result to the HTTP request side.

[0078] Optionally, the cache service layer obtains the response result based on the received HTTP request and sends the response result to the HTTP request side. The cached data of the cache service layer is processed based on the response result, including:

[0079] When the HTTP request needs to read the cached data of the cache service layer, determine the type of the HTTP request. If the request type is write, the cache service layer sends the HTTP request to the HTTP server, the cache service layer receives the response result from the HTTP server, and marks the corresponding cached data as invalid based on the response result, and sends the response result to the HTTP request side.

[0080] Optionally, the cache service layer obtains the response result based on the received HTTP request and sends the response result to the HTTP request side. The cached data of the cache service layer is processed based on the response result, including:

[0081] If the request type is read, determine whether there is data in the cached data stored in the cache service layer that meets the request. If so, read the cached data stored in the cache service layer and generate a response result, and the cache service layer sends the response result to the HTTP request side;

[0082] If not, the cache service layer forwards the HTTP request to the HTTP server, the cache service layer receives the response result from the HTTP server, and after saving the response result, sends the response result to the HTTP request side.

[0083] The basic principles of the present disclosure have been described above in conjunction with specific embodiments. However, it should be noted that the advantages, advantages, effects, etc. mentioned in the present disclosure are only examples and not limitations, and it cannot be considered that these advantages, advantages, effects, etc. are essential for each embodiment of the present disclosure. In addition, the above-mentioned specific details are only for the purpose of illustration and easy understanding, rather than limitations, and the above details do not limit the present disclosure to necessarily adopt the above specific details to implement.

[0084] In this disclosure, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. The block diagrams of devices, apparatuses, equipment, and systems involved in this disclosure are only illustrative examples and do not intend to require or imply that they must be connected, arranged, and configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, equipment, and systems can be connected, arranged, and configured in any manner. Words such as "including", "comprising", "having", etc. are open-ended terms, meaning "including but not limited to", and can be used interchangeably with each other. The words "or" and "and" used herein refer to the word "and / or", and can be used interchangeably with each other, unless the context clearly indicates otherwise. The word "such as" used herein refers to the phrase "such as but not limited to", and can be used interchangeably with each other.

[0085] In addition, as used herein, "or" in a listing of items beginning with "at least one" indicates a disjunctive listing, so that for example, a listing of "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Further, the term "exemplary" does not mean that the examples described are preferred or better than other examples.

[0086] It should also be noted that in the systems and methods of this disclosure, each component or each step can be decomposed and / or recombined. These decompositions and / or recombinations should be regarded as equivalent solutions of this disclosure.

[0087] Various changes, substitutions, and alterations to the technologies described herein can be made without departing from the teachings defined by the appended claims. In addition, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, compositions of events, means, methods, and acts described above. Current or later-developed processes, machines, manufactures, compositions of events, means, methods, or acts that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Thus, the appended claims include such processes, machines, manufactures, compositions of events, means, methods, or acts within their scope.

[0088] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to the broadest scope consistent with the principles and novel features disclosed herein.

[0089] The foregoing description has been presented for purposes of illustration and description. Furthermore, this description is not intended to limit embodiments of the present disclosure to the form disclosed herein. Although several example aspects and embodiments have been discussed above, those skilled in the art will recognize some variations, modifications, alterations, additions, and subcombinations thereof.

Claims

1. An HTTP caching method applicable to RESTFul API, characterized in that, A caching service layer is set between the HTTP request side and the HTTP server side. The HTTP request side is communicatively connected to the caching service layer, and the caching service layer is communicatively connected to the HTTP server side. The method includes: The caching service layer obtains a response result based on the received HTTP request, sends the response result to the HTTP request side, and processes the cached data of the caching service layer based on the response result. The HTTP request comes from the HTTP request side.

2. The HTTP caching method applicable to RESTFul API according to claim 1, characterized in that, The caching service layer obtains a response result based on the received HTTP request, sends the response result to the HTTP request side, and processes the cached data of the caching service layer based on the response result, including: Determine whether the HTTP request needs to read the cached data of the caching service layer. If not, forward the HTTP request to the HTTP server side and receive the response result from the HTTP server side. Based on the response result, determine whether it will cause the cached data stored in the caching service layer to become invalid. If so, mark the corresponding cached data as invalid and send the response result to the HTTP request side. If not, directly send the response result to the HTTP request side.

3. The HTTP caching method applicable to RESTFul API according to claim 2, wherein The caching service layer obtains a response result based on the received HTTP request, sends the response result to the HTTP request side, and processes the cached data of the caching service layer based on the response result, including: When the HTTP request needs to read the cached data of the caching service layer, determine the HTTP request type. If the request type is write, the caching service layer sends the HTTP request to the HTTP server side, the caching service layer receives the response result from the HTTP server side, marks the corresponding cached data as invalid based on the response result, and sends the response result to the HTTP request side.

4. The HTTP caching method applicable to RESTFul API according to claim 3, characterized in that Determine the HTTP request type, including judging the request type according to the operation specification for resources in the RESTFul specification.

5. The HTTP caching method applicable to RESTFul API according to claim 3, wherein, The caching service layer obtains a response result based on the received HTTP request, sends the response result to the HTTP request side, and processes the cached data of the caching service layer based on the response result, including: If the request type is read, determine whether there is data in the cached data stored in the caching service layer that meets the request. If so, read the cached data stored in the caching service layer and generate a response result. The caching service layer sends the response result to the HTTP request side. If not, the caching service layer forwards the HTTP request to the HTTP server side. The caching service layer receives the response result from the HTTP server side, saves the response result, and then sends the response result to the HTTP request side.

6. The HTTP caching method applicable to RESTFul API according to claim 1, characterized in that Used to cache dynamic data returned by HTTP-based APIs.

7. An HTTP caching device applicable to RESTFul APIs, characterized in that, Including a caching service layer, the caching service layer is set between the HTTP request side and the HTTP server side. The caching service layer obtains a response result based on the received HTTP request, sends the response result to the HTTP request side, and the cached data of the caching service layer is processed based on the response result. The HTTP request comes from the HTTP request side.

8. The HTTP caching device applicable to the RESTFul API according to claim 7, characterized in that, The cache service layer obtains a response result based on the received HTTP request and sends the response result to the HTTP request side. The cached data of the cache service layer is processed based on the response result, including: Determine whether the HTTP request needs to read the cached data of the cache service layer. If not, forward the HTTP request to the HTTP server and receive the response result from the HTTP server; Based on the response result, determine whether it will cause the cached data stored in the cache service layer to become invalid. If so, mark the corresponding cached data as invalid and send the response result to the HTTP request side. If not, directly send the response result to the HTTP request side.

9. The HTTP caching device applicable to RESTFul API according to claim 8, wherein The cache service layer obtains a response result based on the received HTTP request and sends the response result to the HTTP request side. The cached data of the cache service layer is processed based on the response result, including: When the HTTP request needs to read the cached data of the cache service layer, determine the HTTP request type. If the request type is write, the cache service layer sends the HTTP request to the HTTP server. The cache service layer receives the response result from the HTTP server and marks the corresponding cached data as invalid based on the response result, and sends the response result to the HTTP request side.

10. The HTTP caching device applicable to RESTFul API according to claim 9, characterized in that, The cache service layer obtains a response result based on the received HTTP request and sends the response result to the HTTP request side. The cached data of the cache service layer is processed based on the response result, including: If the request type is read, determine whether there is data in the cached data stored in the cache service layer that meets the request. If so, read the cached data stored in the cache service layer and generate a response result. The cache service layer sends the response result to the HTTP request side; If not, the cache service layer forwards the HTTP request to the HTTP server. The cache service layer receives the response result from the HTTP server. After the cache service layer saves the response result, it sends the response result to the HTTP request side.

Images