Design for APIConnector Clas

[fgregg]

As per the discussion at the 2025-05-22 Parsons Contributor Meeting, I'm going to work on the APIConnector class. I will create a new class object that will sit along side the existing APIConnector Class, and we can switch the wrappers over to use new class to learn about the design. This will allow for freedom in class design. If successful, we will eventually want to go through and switch all the wrappers, but that's another discussion for another day.

One thing that came from that discussion was that there was two layers for what we would want and APIConnector to do.

1. Supporting the interactions with any site
2. Supporting the interactions with all or many methods of particular site.

For example, for any site, we want to make and receive HTTP requests, communicate errors, and retry on transient errors.

For a particular site, the pagination method for across endpoints will usually be the same, and it would be good to implement that in connector class for that site.

I would split out the list of the requested features in #736 as follows:

All Site	All Methods in a Site
retry logic	polling
default headers	pagination
	unwrapping data
	snakecase to cameCase

This all suggests a two level design, a request Session subclass for the "all sites" methods, and an APIConnnector that uses that subclass.

The simplest thing that could work is start with preserving the

Caveats

Of course, in these clean levels don't stay separated. It's not uncommon, for example for a site to return improper status codes, such as a 200 code with a message saying "no record found." This kind of issues can be handled by providing hooks in the Session subclass to rewrite the status code of a response based upon the body or header of the response.

cc @shaunagm @KasiaHinkson @sharinef1

[shaunagm]

@fgregg it looks like your description cuts off? @ "The simplest thing that could work is start with preserving the"

I'm not sure I understand your distinction between "all site" and "all methods in site" - how are for example retries vs polling different here, in terms of how you're categorizing them?