Highlighted
131 views

REST API design flaws

Hi All,

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.

returns

[

  {

    "id": "string",

    "uri": "string",

    "category": "string",

    "lastDBRefreshTime": "string",

    "data": [

      {

        "cellManagerName": "string",

        "mediumId": "string",

        "mediumLabel": "string",

        "mediaLocation": "string",

        "mediaCondition": "string",

        "mediaProtection": "string",

        "usedSpace": 0,

        "totalSpace": 0,

        "lastAccessTime": "string",

        "mediaPool": "string",

        "mediaType": "string"

      }

    ]

  }

]

 

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".

returns

[

  {

    "id": "string",

    "uri": "string",

    "category": "string",

    "lastDBRefreshTime": "string",

    "durationFormat": "string",

    "data": [

      {

        "cellManagerName": "string",

        "sessionId": "string",

        "sessionType": "string",

        "object": "string",

        "mode": "string",

        "status": "string",

        "startTime": "string",

        "hostsBackedUp": [

          "string"

        ]

      }

    ]

  }

]

 

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?

Cheers
Shane

Labels (1)
0 Likes
1 Reply
Highlighted
Micro Focus Expert
Micro Focus Expert

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: 

https://community.softwaregrp.com/t5/Data-Protection-Idea-Exchange/idb-p/DP_Ideas 

Regards, 

Andres Fallas Salazar
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.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.