Move NexpoesAPI into a new Nexpose::API module about nexpose-client HOT 5 CLOSED

What goal are we trying to achieve?

For me, the problem is that all these methods are just there to mix in to the Connection object. From a documentation point of view, it makes it hard for new users to read through the docs, because they have to know that everything is under the NexposeAPI module, when they really just need to use Connection. The "Nexpose" redundancy is ugly, too.

As to file organization, in general the Connection methods are kept alongside the classes they relate to. So methods on the Connection with return Site information are in site.rb, alongside the Site and SiteSummary classes.

from nexpose-client.

I was attempting to list all of the scan engines (Nexpose::NexposeAPI#list_engines provides this).

What's the point of having a NexposeAPI module in the first place then?

from nexpose-client.

The documentation doesn't show any mention the API methods: http://www.rubydoc.info/github/rapid7/nexpose-client/master/Nexpose/Connection

from nexpose-client.

I haven't traced it back, but the convention was there when I started contributing to the gem. I haven't deviated from it, but had been thinking about it recently as a point of confusion. From a doc point of view, having everything in the Connection class might be the clearest thing.

from nexpose-client.

I agree. You should check out newer clients for guidance on the layout if you have the time to update the current gem. Clients such as the controlsinsight client. I'll also email you with another question.

from nexpose-client.