Sneak peek! REST APIs in ONTAP 9.6

As an employee of NetApp, I have certain privileges. One of those is early access to the latest software releases. ONTAP 9.6 is coming soon, and one of the new features available will be access to REST APIs for cluster management. Because I’m a nice guy, I’ll give a sneak preview of that functionality here.

Previously, if you wanted to manage your cluster, you were either using ssh commands, NetApp tools or proprietary ZAPI via the ONTAP SDK. While this worked fine for the most part, it wasn’t as easily consumable as standard REST API.

What is REST API?

From: https://restfulapi.net/

REST is acronym for REpresentational State Transfer. It is architectural style for distributed hypermedia systems and was first presented by Roy Fielding in 2000 in his famous dissertation.

Like any other architectural style, REST also does have it’s own 6 guiding constraints which must be satisfied if an interface needs to be referred as RESTful. These principles are listed below.

Guiding Principles of REST

  1. Client–server – By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components.
  2. Stateless – Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
  3. Cacheable – Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.
  4. Uniform interface – By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
  5. Layered system – The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot “see” beyond the immediate layer with which they are interacting.
  6. Code on demand (optional) – REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented.

Essentially, it’s a lightweight, easy to use standard way of talking to networked devices.

Where can I find it in ONTAP 9.6?

When you upgrade to ONTAP 9.6, there will be a new directory and link you can access via the normal System Manager web interface. Simply point your browser to https://%5Bcluster IP or name]/docs/api.

Once you do that, you’ll see an easy to navigate man page for the new REST APIs.

rest-api-main

You can click on each DOC link to see more details.

rest-api-docs.png

Below the “doc” section, we also have man pages for each specific category of REST APIs, such as cloud, cluster, network, etc.

rest-api-categories.png

Under the categories, we can see examples and information about each of the available REST API operations:

  • GET allows us to see information
  • POST allows us to create new objects
  • PATCH allows us to modify objects
  • DELETE allows us to delete objects

rest-api-patch.png

There’s also a “Try it out” button – this allows us to generate an API token by authenticating to the cluster and generates a sample curl command and URL.

Once you click “Try it out” you get a series of fields to specify to filter on, and then an “Execute/Clear” option at the bottom (as well as a way to choose response/content type):

rest-api-execute.png

Once you click “Execute” you get prompted for a username/password to generate the API token. Then you get sample curl output, as well as what you’d see in the response of the API:

rest-api-response.png

You also get a “Download” option to download the contents into a .json file.

If you want to generate the API token for external use, click on “Authorize” at the top of the page:

rest-api-authorize

After you do that, our curl command gets an “authorization” option added to it, with a token attached:

rest-api-token

You can take the curl command and copy and paste to a client to run if you like as well. This is how it would look:

#curl -X GET -k "https://x.x.x.x/api/svm/svms?order_by=name" -H "accept: application/json" -H "authorization: Basic [API TOKEN]"
{
"records": [
{
"uuid": "7e3cc08e-d9b3-11e6-85e2-00a0986b1210",
"name": "DEMO"
},
{
"uuid": "fe5a4dfe-d365-11e6-85e2-00a0986b1210",
"name": "NFS"
}

You can also run these via PowerShell using the “Invoke-WebRequest” command:

PS C:\> Invoke-WebRequest "http://x.x.x.x/api/network/ethernet/ports?enabled=true&return_records=true&return_timeou
t=15" -Credential admin -OutFile C:\JP\REST-ports.txt

Then the output file would look like this:

{
"records": [
{
"uuid": "10bd0749-6202-11e9-bc6f-00a0986b1223",
"name": "e0i-689",
"enabled": true,
"_links": {
"self": {
"href": "/api/network/ethernet/ports/10bd0749-6202-11e9-bc6f-00a0986b1223"
}
}
},
{
"uuid": "13352de2-6202-11e9-bc6f-00a0986b1223",
"name": "e0k-689",
"enabled": true,
"_links": {
"self": {
"href": "/api/network/ethernet/ports/13352de2-6202-11e9-bc6f-00a0986b1223"
}
}

With the new REST API functionality, you can now automate with a more standard interface!

Stay tuned for a Tech ONTAP Podcast episode on REST API!

Advertisements

5 thoughts on “Sneak peek! REST APIs in ONTAP 9.6

  1. Pingback: ONTAP 9.6RC1 is available! | Why Is The Internet Broken?

  2. Excellent work as usual. REST APIs sound like a real step forward. But how long will existing ZAPI remain functional? WFA and other tools written against them don’t need to be rewritten immediately, one assumes… but likewise it seems logical that ZAPI will eventually be deprecated then shut off?

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s