Systems and methods for building and providing polymorphic rest services for heterogeneous repositories

Patent metadata

Field	Value
Publication number	US-12289370-B2
Application number	US-202418651953-A
Country	US
Kind code	B2
Filing date	May 1, 2024
Priority date	Aug 9, 2017
Publication date	Apr 29, 2025
Grant date	Apr 29, 2025

Abstract

Responsive to a request to access heterogeneous repositories, a REST server queries a resource registry to find resources that match mapping information contained in the request. The resource registry returns resource registry tables containing the matching resources. The resource registry tables implement a unified data structure of a resource registry model and are generated at runtime by the resource registry mapping REST service configuration parameters to the fields of the unified data structure. The REST service configuration parameters are added to an extension SDK for REST extension developers to enhance REST service configuration for extension applications. The REST service configuration parameters are configured at implementation time and loaded/scanned into the REST server at runtime. The REST server iteratively evaluates the resource registry tables until all the matching resources have been evaluated. The evaluation result is used to determine whether to reject, accept, or redirect the request from the client device.

First claim

What is claimed is:

1. A method, comprising:
in a client-server architecture having a client side and a server side, building a Representational State Transfer (REST) extension at the client side and, at the server side, providing a REST server with an ability to decide, by and within the REST server, which universal resource identifier (URI) contained in incoming REST requests to reject, accept, or redirect,
wherein the ability is based on knowledge gained by the REST server at implementation time and at runtime,
wherein a REST application programming interface (API) is customized with configuration parameters for the REST extension and deployed to enterprise-provisioned repositories at the implementation time, and
wherein a resource registry model is created at the runtime, the resource registry model governing resource endpoints registered with the REST server and used by the REST server to make decisions in the REST server's internal request handling flow, including:
receiving an incoming REST request, the incoming REST request indicating a resource in a target repository, the resource having a URI;
querying the resource registry model or the target repository for a repository type of the target repository so as to gain knowledge on whether the resource is available to the target repository at the runtime, regardless of whether the target repository is a default repository or an enterprise-provisioned repository; and
based at least on the queried repository type, determining whether to accept, reject, or redirect the incoming REST request.

2. The method according to claim 1 , wherein the resource registry model has a unified data structure and wherein the resource endpoints registered with the REST server include a default resource and any modified or customized resources.

3. The method according to claim 1 , wherein the configuration parameters for the REST extension are mapped or translated into fields defined by the resource registry model at the runtime so as to create or update resource registry tables that implement the resource registry model.

4. The method according to claim 3 , wherein the resource registry tables are stored in memory for use by the REST server in evaluating the incoming REST request and determining whether to accept, reject, or redirect the incoming REST request.

5. The method according to claim 1 , wherein the configuration parameters for the REST extension comprise a disabling configuration parameter, an overriding configuration parameter, or a mix of disabling and overriding configuration parameters.

6. The method according to claim 1 , wherein the configuration parameters for the REST extension specify which resources are to be disabled, overridden, or added in a REST extension project, with a repository type.

7. The method according to claim 1 , wherein the configuration parameters for the REST extension are included in a REST extension software development kit (SDK).

8. A system, comprising:
a client-server architecture having a client side and a server side, wherein a Representational State Transfer (REST) extension is built in a client application on a client computer at the client side and, at the server side, a REST server on a server machine is provided with an ability to decide, by and within the REST server, which universal resource identifier (URI) contained in incoming REST requests to reject, accept, or redirect,
wherein the ability is based on knowledge gained by the REST server at implementation time and at runtime,
wherein a REST application programming interface (API) is customized with configuration parameters for the REST extension and deployed to enterprise-provisioned repositories at the implementation time, and
wherein a resource registry model is created at the runtime, the resource registry model governing resource endpoints registered with the REST server and used by the REST server to make decisions in the REST server's internal request handling flow, including:
receiving an incoming REST request, the incoming REST request indicating a resource in a target repository, the resource having a URI;
querying the resource registry model or the target repository for a repository type of the target repository so as to gain knowledge on whether the resource is available to the target repository at the runtime, regardless of whether the target repository is a default repository or an enterprise-provisioned repository; and
based at least on the queried repository type, determining whether to accept, reject, or redirect the incoming REST request.

9. The system of claim 8 , wherein the resource registry model has a unified data structure and wherein the resource endpoints registered with the REST server include a default resource and any modified or customized resources.

10. The system of claim 8 , wherein the configuration parameters for the REST extension are mapped or translated into fields defined by the resource registry model at the runtime so as to create or update resource registry tables that implement the resource registry model.

11. The system of claim 10 , wherein the resource registry tables are stored in memory for use by the REST server in evaluating the incoming REST request and determining whether to accept, reject, or redirect the incoming REST request.

12. The system of claim 8 , wherein the configuration parameters for the REST extension comprise a disabling configuration parameter, an overriding configuration parameter, or a mix of disabling and overriding configuration parameters.

13. The system of claim 8 , wherein the configuration parameters for the REST extension specify which resources are to be disabled, overridden, or added in a REST extension project, with a repository type.

14. The system of claim 8 , wherein the configuration parameters for the REST extension are included in a REST extension software development kit (SDK).

15. A computer program product comprising a non-transitory computer-readable medium storing instructions translatable by a processor of a Representational State Transfer (REST) server in a client-server architecture having a client side and a server side, wherein a REST extension is built at the client side and, at the server side, when the instructions are translated by the processor, provide the REST server with an ability to decide, by and within the REST server, which universal resource identifier (URI) contained in incoming REST requests to reject, accept, or redirect,
wherein the ability is based on knowledge gained by the REST server at implementation time and at runtime,
wherein a REST application programming interface (API) is customized with configuration parameters for the REST extension and deployed to enterprise-provisioned repositories at the implementation time, and
wherein a resource registry model is created at the runtime, the resource registry model governing resource endpoints registered with the REST server and used by the REST server to make decisions in the REST server's internal request handling flow, including:
receiving an incoming REST request, the incoming REST request indicating a resource in a target repository, the resource having a URI;
querying the resource registry model or the target repository for a repository type of the target repository so as to gain knowledge on whether the resource is available to the target repository at the runtime, regardless of whether the target repository is a default repository or an enterprise-provisioned repository; and
based at least on the queried repository type, determining whether to accept, reject, or redirect the incoming REST request.

Assignees

• Open Text Corp

Inventors

• Zhou Wei
• Chen Muhua
• Ruan Wei
• Wang Chen

Classifications

• H04L41/5041

  characterised by the time relationship between creation and deployment of a service · CPC title

• G06F16/951

  Indexing; Web crawling techniques · CPC title

• H04L67/563

  Data redirection of data network streams · CPC title

• H04L67/133

  Protocols for remote procedure calls [RPC] · CPC title

• H04L67/61

  taking into account QoS or priority requirements · CPC title