Refactor Interception logic to use base classes and be compatible with all request types #98
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.
Hi again 😅
This PR is closely related to #94, being an alternative approach to solve the same problem.
Most of what i did and the Inspiration for this is already in #94 and in this comment.
TLDR;
The code uses the
Request
andResponse
class in the interception logic, which then gets wrapped in aRequestData
andResponseData
class.Request
andResponse
are used for specific types of requests and only extend the base class used inside the http logic. This is results in incompatability of the other types of requests, such as:StreamedRequest
andStreamedResponse
MultipartRequest
I just replaced the current usages with the base classes, which enables compatability with all request types. The one downside to this is that you have to check or cast the base classes to the type of request that you are intercepting, in order to manipulate it (such as changing the body of a
Response
).To make this easier, I included
copyWith
extension methods for all requests and responses