PowerStore REST API best practices

Today we live in a world powered by REST APIs. And when it comes to REST API’s, PowerStore’s is fantastic. Why? An important thing to understand is that PowerStore is a REST API first system, which means all functionality that is exposed externally has been made available through the API. This also means that other interfaces such as the CLI or the GUI are in fact consumers of the REST API.

This is the second part of a a recent blog post and a video I published explaining some of the most important features of the PowerStore REST API.

• Blog - http://anzpiper.blogspot.com/2020/08/intro-to-dellemc-powerstore-rest-api.html
• Video - https://youtu.be/xMzKUuTasWY?list=PL_zWoydWWqp4AfdYNkTkAxCvr5tGl9JzR

In this article we will use Postman to show you how to query the API. Postman is a great tool to explore REST API’s and can be downloaded for free

The Postman collection for PowerStore that I am going to show in this article can be found in

https://github.com/cermegno/Project-Vision

Project Vision also has collections for many other DellEMC storage products. If you are not familiar with Postman you might want to explore this article to learn how to import the collection and build an environment for your array:

http://anzpiper.blogspot.com/2019/12/postman-collections-for-dellemc-block.html

Once the collection is imported you can see the 4 API calls on the left pane

The Postman collections in Project Vision use variables to make them more reusable. This means that to direct a call to a different array is as simple as selecting a different environment. On the environment section in the top-right corner I have configured and selected an environment for my PowerStore. The PowerStore collection requires 3 variables (ip, pwd, token) in the environment. The variable “pwd” is the password for the “admin” user. If you need to use a user other than “admin”, you can change it by selecting “edit” on the collection itself

The user you use to query the API is important. It has to have enough rights to perform the equivalent action in the GUI. For example the “/audit_event” resource needs to have the “Administrator” role. For the other resources you can use “Storage Administrator” and even “Operator” roles.

By default the response to “GET” API calls will only return the “id” of the objects in that collection, ex: the internal “id” of every volume for the “GET volumes” call. As discussed in Part 1 of this series, this allow for more responsive queries and a more resource efficient code

When you are exploring an object for the first time you can use the select parameter with “*” wildcard to show all properties.

Ultimately you want to be selective, and retrieve the properties you are after. This is especially true if you are planning to run a query very frequently. You can do so with “select” parameter by specifying a list of the properties you want separated by commas

By default the response comes sorted alphabetically by “id”, ie 1,10,100,1000, 1001,1002 … You can sort the response by any field you want and you can do so in ascending or descending order

In the previous article we mentioned that the PowerStore REST API has a pagination feature. By default it gives you 100 entries but you can choose to show less. This is specially handy if you use it in conjunction with the sorting capability we mentioned above. This is done with the “limit” parameter. In the screenshot below you can see that “limit=5” shows 42 lines of output. If I run the same query without limit it will return 800 lines, which makes sense because 5 is 1/20th of 100. The net result is a more responsive query and more efficient array resource consumption

Finally you can match the type of alerts you want by using the 13 operators supported (ex: gt for “greater then”, lt for “less then” …). Don’t forget the “.” After the comparator. In this screenshot you can see how we are searching for audit_events with a “resource_type” of “volume”