Telerik Reporting REST Services Overview

The Telerik Reporting REST service provides an Application Programming Interface (API) over HTTP to the reports generation engine. This engine allows the exporting of 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.

You can use the Reporting REST service in a JavaScript application without the viewer. Refer to the telerikReportViewer.ServiceClient class in the JavaScript API.

The service has several implementations targeting different web service frameworks which are described in this chapter.

How it Works

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
• Images
• 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 clientId.

Serving a Request

The following steps describe how the Reporting REST service serves a client's request:

1. The client of the service requests a report by a JSON object called a client report source.
2. The service resolves the request to a .NET report source. To do that, it uses a REST Service Report Source Resolver.
3. The service serves the rendered reports as web-accessible resources.
4. The service caches all generated resources in a REST Service Storage of choice.

Configuration Hints

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.