Implement Request Adapter

[baywet]

Looking at the sdk-design features list, there are a number of component that exist today in the graph core library which belong to the kiota http core library. Most of those components are the middlewares. If they exist, move the following components:

• pipeline (if not provided by the native http client)
• authorization handler
• retry handler
• compression handler
• logging handler
• chaos handler
• redirect handler (provided by Guzzle)
• (optional) telemetry handler (make it generic enough so the request
  changes can be specified by a callback)
• multi-part content
• Implement RequestAdapter interface
• Implement KiotaClientFactory

AB#10329

[MIchaelMainer]

To clarify, we don't want the same implementation from our PHP core for Microsoft Graph in Kiota, we want to use our implementation as a reference for adding a generic implementation in Kiota HTTP Core. This is my understanding.

Some of these will not be added to the default pipeline. Is it safe to say that the authorization, retry, and redirect handlers can be added to the default middleware pipeline?

Please check me.

[baywet]

You can look at #360 to get more context and experience feedback from the dotnet work on that aspect.

I don't think we need an auth middleware anymore given the current architecture for Kiota.

The goal is always to put all the non graph specific things in Kiota cores so it's available to others, and keep the graph specific things in Graph core, so we have a good feature set for graph users.
When possible and required, things should be made generic and extensible, such as the work that's been done on #609 for the telemetry handler.

In terms of the defaults, I'd argue that most if not all middlewares defined in kiota http core should be part of the defaults, unless you have a specific point?
Then, GraphCore, can always "rework the defaults" provided by kiota core (removing some if required, adding the graph specific ones).

Let me know if that answers most questions here, and don't hesitate to ask follow up questions.

[Ndiritu]

Notes for future reference:

• Guzzle provides a built-in Redirect Handler that meets our SDK design requirements including our security consideration on not sending Authorization tokens to a different host
• Guzzle supports decompression by default by relying on curl to add Accept-Encoding headers & decompress request bodies. Decompression can be configured further using the decode_content Guzzle config option.
• Guzzle provides built-in logging middleware (https://github.com/guzzle/guzzle/blob/master/src/Middleware.php#L192)
• Guzzle's built in MockHandler handles "Manual mode" scenarios defined by Chaos Handler design spec. The PHP Chaos Handler will only handle "random mode" scenarios.