4. Cleaning Up

Now that the exchanges are captured, we can clean up the collection by removing any unnecessary exchanges or variables. This is a good practice for multiple reasons:

• It makes the collection easier to read and understand.
• Best part is no part, the fewer exchanges you have, the less you have to maintain.
• Improves performance, the less data the software has to process, the faster it will be.

The Difference Between Removing and Disabling

With API Parrot, you can either delete a request or disable it. The difference is that a disabled request is still stored in the collection but does not do anything. This can be useful if you want to keep the request for later but don't want it to run at the moment. A deleted request is removed from the collection entirely.

Variables can only be disabled, not deleted. When you disable a variable, any variable with that exact value will be disabled, even if it is used elsewhere in the collection.

Removing Unnecessary Exchanges

Most often, you will have exchanges that are not necessary for the collection. These are often trackers etc. that are not actually needed for the functionality to work. API Parrot will try to automatically detect some of these exchanges and automatically disable them. However, it is always a good idea to go through the exchanges and see if there are any that can be removed.

A useful tip is to sort the exchanges by the Endpoint column, this will group exchanges to the same endpoint together, making it easier to remove all the exchanges from a specific endpoint, for example a tracking provider.

In this example, after grouping by endpoint, we see that we got exchanges to "content.autofill.googleapis.com", "region1.googleanalytics.com" and "www.google.com". These are not necessary for the USPS ZIP Code Lookup to work, so we can safely remove them.

We can now switch over to the flow view to see the exchanges in a more visual way. Here we are also able to see the variables API Parrot has detected.

In this example, we can see that exchanges 0002 and 0003 are grouped together, this is becuase API Parrot has detected that request 0002 redirects to request 0003. Since these exchanges are essentially the same, and we can see that request 0002 is only trying to fetch a stylesheet, we can safely remove it, since the style.css is unlikely to be needed for the functionality to work. One way to do this is by selecting both exchanges by holding down Shift and dragging the mouse over the exchanges, then pressing the Delete key.

To read more about the flow view, see the Flow View section.

There are now only 2 request left in the collection, this is a simple example, for more complex use cases, there will propably be quite a few more exchanges left in the collection.

Disabling Unnecessary Variables

After removing the unnecessary exchanges, we can now go through the variables and see if there are any that can be disabled. In our case, we see that API Parrot has detected four variables:

• tltsidCookie = 87599165d85a1663890000e0ed96a2ca
• nscUppmtUsvfOfxCookie = ffffffff3b462a2245525d5f4f58455e445a4a4212d3
• attributeClass = tools
• attributeAriaExpanded = false

note

Variables are detected by API Parrot by identifying values that match between multiple exchanges. For example, in this case, the 87599165d85a1663890000e0ed96a2ca was found in the response of request 0001 and in the request of request 0010, the software then assumes that whatever will be seen in the same position in future responses of 0001 also has to go into the same position in future requests of 0010. In API Parrot, variables can have one source (reponse from which the value is set) and multiple targets (requests where the value is used). In this particular case, tltsidCookie is set in the response of request 0001 and only used once in request 0010. Read more about this in the Exchange Model & Varuable Detection section.

Of these variables, tltsidCookie and nscUppmtUsvfOfxCookie are likely to change between sessions, however, attributeClass and attributeAriaExpanded are unlikely to change and can thus be treated as static values. We can therefore disable the attributeClass and attributeAriaExpanded variables. One way to do this is by selecting the variables, right-clicking and selecting Disable or pressing Ctrl + D (Linux/Windows) or ⌘ + D (macOS).

note

We do not know for sure that tltsidCookie and nscUppmtUsvfOfxCookie are actually needed for the API to work, however, let's assume that they are needed for demonstration purposes. In cases there you need to sign in to a service, such cookies are often used to keep track of the session and are therefore necessary for the API to work.