Handling Virtual REST APIs with Multiple Resources
The enhanced REST framework of CentraSite Business UI allows you to explicitly define multiple resources for a RESTful API. Each resource within the API exposes a unique URI for performing the CRUD operations on the resource.
CentraSite provides the resource path tokenizer to support the multiple resources handling at run-time. The tokenizer for substituting a resource path is automatically appended to the API’s endpoint (base URL) by a path variable ${sys:resource_path}. When there are multiple resources defined for an API, at run time, Mediator replaces the resource path tokenizer with the appropriate resource path that is defined for the particular resource call.
Important: | Beginning with version 9.7, CentraSite supports the multi-resource handling of the REST interface at run-time (in contrast, earlier versions of CentraSite supported a single resource handling). Note that the enhanced REST interface that is implemented by current version of CentraSite is not compatible with the interface that was implemented by previous versions of Mediator prior to version 9.7. However, if you still attempt to publish a virtual REST API with multiple resources to an earlier version of Mediator instance, Mediator throws an exception message. |
Let's now learn about the usage of resource path tokenizers in CentraSite by looking at a couple of examples using our sample phone store API.
Consider you have a plain REST API PhoneStoreAPI with a defined set of resources for performing the CRUD operations.
Assume you have the PhoneStore API with the following configuration details:
Base URL:
http://www.phonestore.com/api
Resource:
phones
Resource URI:
/phones
Native Endpoint:
http://www.phonestore.com/api/phones
Beginning with version 9.7, on a virtual copy of this API, CentraSite appends the resource path tokenizer ${sys:resource_path} to represent its Route to endpoint like this:
http://www.phonestore.com/api/${sys:resource_path}
In the aspect of this resource path tokenizer, there are two principal scenarios, when consumers attempt to model virtual REST APIs with multiple resources.
