renames request info to request information

[baywet]

• renames request info into request information to avoid conflicts
• bumps patch version

fixes #551

Generation Diff

microsoft/kiota-samples#244

[nikithauc]

@baywet I strongly recommend using Context as a suffix to the class name because:

1. As I mentioned before in the issue, it would conventional and easier to understand the purpose of the class.
2. The class in discussion deals with any information used by the middleware. The middleware deals with requests, responses and can be extended by any user to add more features such as session, cache or information dealing with only the responses.

[baywet]

I might be biased here but to me "context" involves some kind of heavy object that's longed lived, but it's probably because of entity framework or the application context in winforms or the app insights telemetry context.
Our request information on the other hand is lightweight and short-lived.
I believe that dotnet devs will feel the same way, arguably TS/JS devs might not.

[MIchaelMainer]

You did describe it as an "...abstract HTTP request". If that description is correct, consider naming to mirror as you described it: AbstractHttpRequest.

For example, does it make sense to authenticate the RequestInformation object, or to authenticate the AbstractHttpRequest object?

[baywet]

Thanks for the suggestion.
Abstract: we're already in the abstraction package, it's redundant.
Http: we're in the abstractions, and would like to stay protocol agnostic

Which leaves us with Request, which is probably going to conflict with a bunch of platform types.
Trust me, I've thought about what to name this class for a while 😂.

Any other suggestion?

[baywet]

Another good candidate I had was RequestDetails, but it's a plural and I'm not sure it'll work for some naming conventions (thinking of java here)

[darrelmiller]

For better or worse, "context" objects have a pattern of providing both input and output as they contain the context around the operation. The request object should be kept purely as input. It also isn't abstract. Creating an instance of a class that is call abstractXYZ would be counter intuitive.

What's the objection to requestInformation? Having an auth token as part of requestInformation seems fairly natural even though the name is quite long.

[MIchaelMainer]

The class is active with many methods, so it feels more than informative. It is nearly an HttpRequestMessage or a Fetch Request object, with some additional functionality.

Yeah, we already define RequestContext for use in our middleware. This is different.

I can't come up with another idea that doesn't degrade from RequestInformation or that doesn't start colliding with existing concepts.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

92.9% Coverage
0.0% Duplication