The Telerik Reporting REST service provides an Application Programming Interface (API) over HTTP to the reports generation engine. This engine allows exporting report documents in all supported rendering formats. The server-client communication relies on simple Data Transfer Objects (DTOs). All DTOs are JSON encoded.
The primary usage of the service is in the HTML5 Report Viewer ecosystem. It leverages the pure client-side implementation of the viewer.
The service has several implementations targeting different web service frameworks which are described in this chapter.
The Reporting REST service exposes all report generation assets as web resources that can be accessed from specific web endpoints. These exposed assets include:
- Report instances
- Report documents
- Other rendered report meta-data
To access these report generation assets, a client host issues a set of requests and wraps them in a client session identified by a
The following steps describe how the Reporting REST service serves a client's request:
- The client of the service requests a report by a JSON object called a client report source.
- The service resolves the request to a .NET report source. To do that, it uses a REST Service Report Source Resolver.
- The service serves the rendered reports as web-accessible resources.
- The service caches all generated resources in a REST Service Storage of choice.
You can configure the report service in the application's configuration file - either .config or .json for the different service implementations. For more details, see restReportService Element.
Furthermore, each of the steps listed above allows you additional configuration and customization, for example:
The client session expires within a particular time, which can be configured. That said, within a single client session, the same request will always return the same cached resource.
An exception is the Register Client endpoint, which can enforce regeneration to support the Refresh Report functionality. To achieve that, add a useCache = false setting to the request's body.
In some scenarios, you need to share the service with more than one app. For these, you may need to turn on Cross-Origin Resource Sharing.
- If all new report requests get executed simultaneously, the host will get overloaded. To avoid this, the service executes the report generation requests in a task queue. The count of the simultaneously rendered reports is configurable.
- In some scenarios, you need to host two or more report services in a single application. To achieve that, assign a unique HostAppId property to each implementing controller. This will produce a dedicated task queue for each service instance. Additionally, you must set the appropriate worker count for each queue to avoid system overload.