Dell PowerStore 9000T EMC PowerStore REST API Developers Guide - Page 6

1 Overview The PowerStore Management REST API The PowerStore Management REST API is a set of resources (objects), operations, and attributes that provide interactive, scripted, and programmatic management control of the PowerStore cluster. Here are some examples of what you can do with the REST API: • Provision new cluster components, such as appliances and volumes. • Configure replication destinations and sessions, and rules. • Fail over and fail back an appliance. • Create snapshots for backup purposes. • Gather metrics to use for historical analysis. • Gather configuration information and logs to use for auditing and trending analysis. For more information about PowerStore Management REST API functionality, see Reference content. Reference materials are also available on the appliance in several formats: • Swagger UI-https:///swaggerui • JSON-https:///api/rest/openapi.json • HTML-https:///api/rest/doc.html The REST API uses a Representational State Transfer (REST) architecture style to expose data. Using a REST API provides the following advantages: • Presents a single, consistent interface for managing PowerStore clusters. • Requires no additional tools, other than standard web browsers or command-line HTTP tools, such as wGET and cURL. For complex interactions, clients can use any procedural programming language, such as C++ or Java, or scripting language, such as Perl or Python, to make calls to the REST API. • Uses well known HTTP conventions in a standard manner to interact with the appliance. • Is easy to transport in the network. REST API traffic looks and acts like standard HTTP network traffic, and requires no special ports open in the firewall or special settings in the switches. The REST API connection is secured with SSL. The same authentication is used for the REST API and GUI. Resource-oriented architecture and REST REST is a client/server architectural style that uses the HTTP protocol in a simple, effective, way. REST is based on the following principles: • Application state and functionality are organized into resources. Resources represent physical things, such as a specific appliance. Resources also represent logical things, such as a specific alert, or collections of entities, such as the volumes or virtual disks in the system. • Each resource has a unique Universal Resource Identifier (URI), and each resource instance has a unique ID. For example, you can identify the alert collection with this path component: /api/rest/alert, and you can identify the alert instance that has an ID of 00c0d863-8a13-4e98-ba06-c4c3f6da615f with this URI: /api/rest/alert/00c0d863-8a13-4e98-ba06-c4c3f6da615f. • Resources share a uniform interface between the client and server through standard HTTP protocol operations. The PowerStore Management REST API uses the HTTP GET operation to retrieve data about a resource collection or resource instance, PATCH to modify a resource instance, POST to create a resource instance, and DELETE to delete a resource instance. The REST API also uses POST for a limited set of other operations to implement resource-specific actions. Thus, an application can interact with a resource by knowing the URI pattern, resource identifier, and action required. • Communication between the client and server occurs through HTTP requests and responses. In the PowerStore Management REST API, requests and responses represent resource data using JavaScript Object Notation (JSON). • Each request is stateless, which means that the server does not store application state information. Instead, client requests contain all the necessary information to service the request. • Resources in a REST API are self-documenting. A response from the server contains information about the requested resource in the form of attribute names and values. 6 Overview