iControl REST 101: ASM Intro

The iControl REST 101 series has covered most of the basics that you should need to get started developing against this new, lightweight API. As a recap, so far we’ve covered:

· What is iControl REST?

· Getting Started

· Creating Objects

· Modifying Objects

· Deleting Objects

With that you’ve got most of the standard bases covered. What you might need, however, is a little help delving into the more advanced functionality that iControl REST offers.

In this installment we deal with something that is advanced due to the nature of its implementation. Given that it strays a bit from the model of mirroring tmsh commands the ASM support built into iControl REST may take a little bit more time to pick up. Those that were familiar with tmsh before touching iControl REST at all have surely seen how easy it is to transition. iControl REST is, after all, built on top of all of the pre-existing tmsh commands.

What happens when there aren’t tmsh commands, though? While tmsh support for ASM is certainly something that’s been tossed around more than once, we didn’t want to leave any modules out in the meantime. That means we rolled in some custom commands that iControl REST can use to manipulate your ASM deployment. This is good news, as it means that you can maintain continuity with your management and automation scripting, even while making use of some of our more advanced modules, such as ASM.

First and foremost, you should absolutely familiarize yourself with the iControl REEST user’s guide (available here for 11.5.0), as we’ll be drawing on that extensively for resources. Now that that’s out of the way, let’s dig in.

As this is a more advanced module, the commands are a bit more advanced as well. Nothing we can’t tackle, but we’ll have to break it down a little bit into pieces that are consumable. Let’s take a look at how they work.

As with all other iControl REST methods, the type of action is defined by issuing different types of HTTP calls. The methods that iControl REST supports for ASM are:

GET, POST, DELETE, PUT, PATCH and “Other”. Note that “Other” isn’t directly a method in the sense that it isn’t specific in the HTTP method type itself, but rather in the HTTP body of a POST. Each of these methods works with the prescribed parameters, operators and namespaces.

We’ll cover parameters, operators and namespaces in the next article. For now let’s just take a look at what connecting to an ASM device looks like, and leave the rest. Just like the rest of the iControl REST infrastructure the ASM namespace is discoverable. All you need to do is make a GET request to see the available resources, as is shown in the user’s guide:

GET https://192.168.25.42/mgmt/tm/asm

… and this carries on for the rest of the items in the return list.

Once you have a list of the resources, as above, you can dig a bit deeper to get the details of a given resource pass another GET to one of the specific resource URLs, which will expand upon what is available. This looks like:

GET https://192.168.25.42/mgmt/tm/asm/policies

… and again, this carries on depending on the running config.

As you can see, at least the listing of objects and items is very much the same as what you’re used to in the rest of ASM. Next time we’ll dig in a bit more to creating and modifying objects which will look a little bit different.