REST API design flaws
I don't quite understand how some of the REST APIs have been structured between the Cell Server and the Reporting Server . These are summarized into the 2 sets:
REST API Categories (Set A) - RUNS FROM CELL SERVER
Authenticate: API to manage tokens required by all other APIs for their execution. This is the first API to be invoked to authenticate to Cell Manager.
Schedules: Collection of APIs to manage all Micro Focus Data Protector schedules
Jobs: Collection of APIs to manage Micro Focus Data Protector jobs. A job is associated with a Micro Focus Data Protector specification. Per specification, a Job ID is associated internally.
Specifications: Collection of APIs to query various Micro Focus Data Protector specifications. The responses from these APIs can be framed as input body while calling a Job API Executions: Collection of APIs to manage Micro Focus Data Protector jobs via Scheduler.
Time Intervals: Collection of APIs to query schedules in a given time interval.
Restore: APIs to manage restore operations of various data sets.
Sessions: APIs to list and restore Micro Focus Data Protector sessions.
License: APIs to get license related information.
REST API CLI Bridge: APIs for running Micro Focus Data Protector CLI commands and REST API bridge configurations.
REST API Categories (Set B) - RUNS FROM REPORTING SERVER
Configuration Reports: APIs to retrieve configurations related to Sessions and Cell Manager
Pools and Media Reports: APIs to get information about Media, Media Pools and related statistics
Sessions in Timeframe Reports: APIs to get Sessions related information over specified time period.
Advanced Reports: APIs to retrieve in-depth information about sessions, capacity and future trends.
Compliance Reports: APIs to get compliance related information.
Configuration Settings: APIs for configure Reporting Server.
Report Configuration Settings: APIs to operate on Reporting Server.
We can successfully do some really complex things via the Set A REST APIs but then get crippled by the fact that some very basic API calls are lobbed into Set B where a Reporting Server must exist (licensed) and then even if it does exist, does not have real time data.
The following are just two examples of very basic API calls tied into SET B.
Media List :/dp-reporting-gui/restws/reporting/media-list
API provides a detailed list of media with various attributes.
Session List within timeframe : /dp-reporting-gui/restws/reporting/list-of-sessions
API provides basic information about sessions in a given time frame. To get advanced information about sessions, view "Advanced List of reports".
There is nothing in the returned contents of these 2 API calls that is sophisticated or can’t be generated from CLI commands on the cell server.
How would one go about using a REST API to efficiently return DP sessions run in last 30 minutes and be confident that accurate data will be returned !?!
One solution is to use the REST API CLI Bridge , but is clunky and can involve significant additional programming.
Can anyone comprehend why Microfocus have packaged these simple REST API calls this way?
Re: REST API design flaws
Hello @Shane Hocking,
As I know, the RS do not sync the info and reports via API, it is with the synchronization of the database done at the times specified.
If you have requests for improvements, you can do them here:
Customer Support Engineer
If you find that this or any other post resolves your issue, please be sure to mark it as an accepted solution.
If you are satisfied with anyone’s response please remember to give them a LIKE by clicking on the bottom at the left of the post and show your appreciation.