Nimbostratus
When we first designed the API, it had the following goals
1. Ease of use
2. Extensible
3. Backward compatible
With these in mind, the object by object operation and property accessor model fit most closely. If, for instance, we created a method to retrieve all attributes of a Pool, then if an attribute was removed or a new one was introduced, we would need to create a new method to account for this. This would end up with multiple methods that do the same thing and we believe would cause confusion for the developer.
The same issue applies with a "global" method that returns everything in one big swoop. The signature for this method could never be constant over time. In versions past v4.2 of BIG-IP, we've introduced "bulk" type methods that allow returning lists/statistics/attributes for more than one object in a single request. This would not compromise backward compatibility but could ease the burdon of round-trip times.
Another problem with one "big" method that returns everything relevant is that "everything" is relative to user. To return a entire configuration for a site that has a mammoth configuration (10000 virtual servers - yes we have customers like this), the returned stream would likely cause major problems with client parsers as well as server side memory consumption.
The biggest issue with Perl that I've seen is the SSL negotiation required for each message. As far as I know there is no way to use HTTP keep-alive, but that could solve that problem if it's possible in the SOAP::Lite package.
If you believe you have a solution that addresses our requirements, please let us know as we are very committed to making the life of the iControl user as "pain-free" as possible.
-Joe
