Those are very good questions. The inconsistency between private/public is unfortunate. As you point out some of the classes lack the connection fields. Apart from that some fields with the same names have have different types for the various classes. It feels like those fields are more of an implementation detail, and perhaps they should all have been private. On the other hand all those classes represent http requests, so the code can also be refactored by pulling those fields up into a common super class.

What are you trying to achieve? Why do you need access to the fields?

On the other hand all those classes represent http requests, so the code can also be refactored by pulling those fields up into a common super class.

This sounds like a good idea to me 👍. I think at least requestNode could be pulled up into the super class because, after all, all these classes do represent an HTTP request. So it'd be natural to include the node of the request in the public API of the class.

The connectionNode nodes are a commonality among some, but not all, HTTP request classes. Oftentimes these HTTP request frameworks have a way to create a connection pool and use that to make requests rather than create a new connection for every request. I'm not sure the best way to represent this in QL, but some kind of optional (i.e. present or null/nil//etc) class field makes sense to me.

What are you trying to achieve? Why do you need access to the fields?

I'm building on these HTTP request classes to analyze the HTTP headers used in these various frameworks. For example, say we have the following code:

require 'faraday'

# requestNode
resp1 = Faraday.get('http://example.com', nil, {'somekey' => 'somevalue'})

# connectionNode
conn = Faraday.new(
  url: 'http://example.com',
  headers: {'somekey' => 'somevalue'}
)

resp2 = conn.get('/')

The easiest way to find these request and connection calls is to use something like FaradayHttpRequest. And then I can write QL code to use requestNode and connectionNode to analyze the call's HTTP headers. I came up with this by reading through the relevant Ruby queries and libraries, so let me know if there's a better way to accomplish this objective. But, overall, creating a custom class that extends FaradayHttpRequest has been a great, succinct way to accomplish this.