CASMCMS-9225: Create generic endpoint classes #397
+476
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When investigating the apparent resource leaks in BOS, I discovered that simply preventing the request timeouts or limiting the response sizes was not sufficient. I found that I also needed to place context managers around request sessions, HTTP adapters, and request responses. (Note -- I also learned that only using the context managers was not sufficient to solve the problem). The problem is, the BOS code uses requests sessions in various places. In some cases, the session is passed in as an optional argument. In other cases, there are long-running sessions, or sessions that last the lifetime of the BOS operators. I realized that to avoid making a ton of hacky fixes all over the place, it would simplify things if I refactored the code BOS uses when interacting with APIs.
This PR is the first step in that process. It introduces classes that represent API endpoints.
BaseGenericEndpoint
is the fundamental endpoint class. It defines some of the common functions (like how to construct the endpoint URLs from a URI, and how to make the API requests). It does not make assumptions about what data the caller wants back from the request. That is why it is aGeneric
. It provides a default exception handling strategy, but it can be overridden in subclasses. I did this because this was another case where we had a fairly scattershot approach in the repo to how we dealt with request exceptions. A couple of places did basically the same thing, but repeated largely the same code. Other places did not handle all of the possibly exceptions.BaseRequestErrorHandler
is the fundamental exception handler class. It could also have been defined as a protocol, since it is essentially just specifying what an error handler must do in order to work with the endpoint class.RequestErrorHandler
is the default exception handler class. I created it based on the best exception handling code that we had in the BOS repo. It is created in such a way that it can be easily subclassed if all you want to do it handle one specific exception type differently (this was the case with IMS, as will be seen in a later PR).BaseEndpoint
is the "default" base endpoint class. By default I mean that it is the one most of the endpoints use, because it just returns the content of the body of the response (after parsing it as JSON, if it is not None). That is what most of the BOS API clients care about.BaseRawEndpoint
is the other endpoint class. It returns a collection of data from the response, in the form of theResponseData
class. This is used so that we can put the actual request response inside a context manager, and close it out. The BSS client endpoint ends up needing data from the header of the response, so it ends up using this class.This PR does NOT make use of any of the above classes yet. The following PRs will do that.